Agent Architecture and Orchestration
Agent Definition — Stack
Agent definition › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing how a behaviour is written down, who can change it, and what a change has to survive before it ships.
- Who must be able to read a diff. If prompt wording is owned by support leads or legal reviewers, a Python class in a repository is the wrong home for it no matter how elegant.
- Revision retrieval. Given a transcript from six weeks ago, can the exact instruction text, tool list, and model revision that produced it be recovered?
- Contract enforcement. Whether input and output shapes are declared in a form something validates, and whether validation happens at load time, call time, or never.
- Tool binding. Whether tools are referenced by stable identifier, pulled by name from a live catalogue, or inlined — this decides whose change can alter this agent's behaviour.
- Standalone exercisability. Whether the artefact can be loaded and run against a fixture set in continuous integration without starting the surrounding product.
- Enforceable limit fields. Whether the format has somewhere to put a spend ceiling or a tool allow-list that the runtime honours, or whether such things can only be prose.
- Portability. How much of the artefact survives a change of agent runtime, and how much is framework-shaped glue that would have to be rewritten.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Code-first agent SDKs (OpenAI Agents SDK, Claude Agent SDK, Pydantic AI, LangGraph, Google ADK, Strands Agents) | Engineering-owned agents where typed tools and tests matter more than editability by others | The artefact and the runtime become inseparable; non-engineers cannot change a sentence without a deploy |
| Declarative manifests (CrewAI YAML, AutoGen configuration, Semantic Kernel agent YAML) | Fleets of similar agents where the shape is fixed and only the content varies | Expressiveness ceiling arrives fast; conditional behaviour ends up smuggled into prose |
| Prompt management platforms (Langfuse, PromptLayer, Humanloop, vendor prompt registries) | Teams where wording changes ship on a different cadence from code | Splits the artefact in two — the platform holds the words, the repo holds the tools, and only their combination is testable |
| Typed contract libraries (Pydantic, Zod, JSON Schema) alongside any of the above | Making the return shape enforceable rather than hoped for | Schemas constrain structure and say nothing about whether the content is right |
| Interoperable description formats (A2A agent cards, MCP server and tool descriptors) | Agents that must be discoverable or callable outside the team that built them | Describe the public surface only; the instructions behind it still need a home |
| Visual and low-code builders (vendor agent builders, workflow-editor agent nodes) | Getting a first version in front of users without an engineering queue | Export fidelity is usually poor, and review of a change means looking at a canvas, not a diff |
| Fine-tuned weights as the behaviour carrier | Narrow, extremely high-volume behaviours where prompt length is the cost driver | Behaviour is no longer legible or editable; every change is a training run and a new evaluation |