loading…
Place protocols at the correct system boundary: tools, agents, users, and transactions.
| Boundary | Typical interface | Purpose |
|---|---|---|
| Model / agent ↔ tool or data source | MCP, function calling, APIs | Discover and invoke bounded capabilities |
| Agent ↔ independent agent | A2A or custom messaging | Delegate tasks, exchange status and artifacts |
| Agent ↔ user interface | Declarative UI contracts | Render safe, structured interactions |
| Agent ↔ high-impact transaction | Application-specific authorization and payment controls | Prove intent, scope, and approval |
A tool exposes a bounded operation with a defined contract. An agent may interpret a goal, perform long-running work, ask questions, and return multiple artifacts. Do not wrap every complex service as an "agent," and do not treat an open-ended collaborator as a synchronous function if it needs task state and negotiation.
When a model influences an interface, prefer declarative structures that reference trusted components rather than executable code. The client renderer owns the component library, security policy, and final behavior.
Protocols evolve. Teach the stable architectural boundary first, then verify the current specification before implementing transports, fields, or authentication details.