Web Directions Year round learning for product, design and engineering professionals

AGENTS.md Is the Wrong Conversation

The AI industry is in specification-mode. How should agents communicate? What should the protocol look like? How do you define a standard so that agents built by different organizations can interoperate? There are frameworks, working groups, proposals for standardization. The energy is palpable. Finally, we're going to solve the agent problem by nailing down the technical spec.

But Jakub Riedl sees this as the wrong conversation entirely. The problem with agents isn't how they talk to each other. It's what they actually know about the systems they operate in.

Consider a practical example. You deploy an agent to help with customer support. The agent can talk to the ticket system. It can read customer history. But does it understand what operations it's actually authorized to perform? Does it know the difference between actions it can take and actions that require human review? Does it understand the consequences of different choices? Does it have any way to know if it's about to do something catastrophically wrong?

These aren't protocol questions. They're context questions. They're about what the agent fundamentally understands about the domain it operates in.

This is the gap that specification-focused conversations miss. You can define a beautiful protocol for how agents communicate. You can build interoperability between systems. But if the agent doesn't understand the domain it's operating in, the protocol doesn't matter. The agent will be dangerous, unreliable, or both.

Think about what an agent actually needs to know. In a financial system, it needs to understand limits—what amounts can be transferred without approval, what checks are required, what audit trails matter. In a healthcare system, it needs to understand regulations, privacy constraints, what information can be shared with whom. In an e-commerce system, it needs to understand business rules—what discounts can be applied, what refund policies exist, when customer service escalation is required.

This knowledge lives nowhere currently. There's no standard way to express it. There's no agreed-upon format for "here's what this agent is allowed to do and why." Teams hand-code it into prompts or system instructions. Different agents learn it different ways. There's no reusability. There's no standardization.

But more importantly, there's no clarity. The agent doesn't know what it doesn't know. A human reading a prompt can ask clarifying questions. An agent just follows the instruction and hopes for the best. If the context is incomplete or ambiguous, the agent finds out through failure.

What if the focus shifted to solving this problem instead? What if we developed standards for expressing domain context—not as prose descriptions, but as structured knowledge that agents could actually understand and reason about? What if we built tools for documenting what agents are allowed to do, what the constraints are, what the failure modes look like?

This is harder than protocol design. It requires collaboration between domain experts and technologists. It requires accepting that different domains need different representations. But it solves an actual problem instead of a theoretical one.

The protocol conversation assumes that once agents can communicate, the hard problems are solved. They're not. The hard problem is knowing what to do—understanding the domain and operating safely within constraints that matter.

The organizations that succeed with agents won't be the ones with the most compliant protocols. They'll be the ones that figured out how to give their agents genuine understanding of the domains they operate in.

Jakub Riedl is shifting the conversation away from agent protocol standardization to the harder, more important problem of agent context and domain understanding at AI Engineer Melbourne 2026 on June 3-4, arguing that we're optimizing the wrong thing.