An AI agent, in the sense the Guild uses the word, is software that pursues a defined mission by taking actions — reading information, calling tools, updating systems, asking people — inside limits a person has set. The limits are what separate an agent you can put to work from a clever demo.
Most agent failures are not model failures. They come from decisions made late, or not at all: what the agent is for, what it may touch, what it knows, who it hands over to and how anyone will tell whether it works. The public guidance points the same way: OWASP lists excessive agency — an agent given more functions, permissions or autonomy than its job needs — among the main risks of LLM applications. So the Guild starts with the architecture around the model, and only then with techniques.
Questions this topic answers
- Should this work be an agent at all, or a rule, a form or a fixed workflow?
- What does a production agent need besides a model — knowledge, tools, memory, limits?
- Where must a person approve, and how do we keep that fast?
- How do we know an agent is ready, and that it stays ready after every change?
- When does one agent become several, and what holds them together?
- Who owns the agent once it is live?
A reading path
- When a business should not build an AI agent — eight signs an agent is the wrong tool, and what to build instead. Read it before you commit.
- The complete guide to AI agent architecture — from a single agent with one tool to a governed guild of agents, with the decisions in the order they matter.
- Building a Production AI Knowledge System — Field Guide 017: how an agent gets accurate, permitted, cited knowledge.
- Agent permissions and tool boundaries — where an agent's permissions are actually enforced, because the model is not a security boundary.
- Human Approval Patterns for AI Agents — Field Guide 014: where a person must decide, and how to keep the hand-off fast.
- Agent Production Readiness Kit — Evaluation Kit 001: the scenarios, scorecard and thresholds behind a signed go/no-go.
For specific design choices, go on to Memory is not a database, Persistent vs ephemeral agents and Multi-agent orchestration. For how people and agents work as one team, read The operating system for an agentic future.
Key ideas
- Mission — the work an agent exists to do, for whom, what counts as done, and what it must never do.
- Tools — the systems an agent may call. Every call is an action with consequences, so each tool is allowlisted and bounded.
- Knowledge — approved, owned content the agent answers from, with citations. Operational data is different: the agent queries it through tools.
- Memory — what an agent keeps from its own work. Useful, risky, and a design decision of its own.
- Boundaries — identity, allowed tools and actions, data access, limits and escalation rules, enforced outside the agent.
- Human checkpoints — the decisions that stay with a named person, routed so that they stay fast.
- Evaluation — scenarios, scorecards and thresholds that decide readiness, run again whenever the model, instructions, tools or knowledge change.
- Autonomy levels — Observe, Assist, Operate, Optimize. An agent moves up on evidence, by a person's decision, and can be stepped back down.
- The operating layer — the missions, owners, approvals and records around the agents. In the Guild, that is the Citadel.
Before you build one
Five questions decide most of what follows:
- Can you state the mission in two sentences, including what the agent must never do?
- Which tools will it call, and what is the worst single action those tools allow?
- Which approved sources will it answer from, and who owns each one?
- Which decisions stay with a person, and who is that person?
- Which scenarios and thresholds will decide that it is ready — and who signs?
If any answer is "we will see", start with The Governed Agent Blueprint, which turns these into seven decisions with an owner each.
Every agent the Guild deploys receives a role, an identity, approved tools, explicit limits, evaluation criteria and a named Human Wizard. When the answers are clear, AI Agent Development turns one workflow into a governed agent, and the Evaluation Lab measures whether it deserves more autonomy.
