An AI agent looks mysterious from the outside because it seems to move through a task by itself. Inside, the parts are understandable.
There is a model that can interpret the goal. There are tools that let it act. There is context that tells it what happened so far. There are rules that limit what it may do. There is often an orchestrator that decides which agent or tool handles which part. There should be logs, evaluations, and a way for a person to interrupt.
The craft is in how these pieces are assembled.
The model
The model is the reasoning engine. It reads the user’s goal, the system instructions, the available tools, and the results of prior steps. It decides what to do next.
Models have become more useful for agents because they can handle longer context, reason through multi-step tasks, write and inspect code, process images, and call tools in structured ways. But the model is still not the whole agent. A brilliant model with no tools can only talk. A weaker model with well-designed tools may perform a narrow workflow reliably.
The tools
Tools are how the agent reaches the world.
A tool can be simple: search this database, read this file, send this email draft for approval, run this test command. A tool can also be broad, such as a browser, a shell, or a computer-use interface that lets the model operate software visually.
OpenAI’s Responses API and Agents SDK placed web search, file search, computer use, orchestration, and tracing close to the center of agent development. Anthropic’s computer use gave developers a way to let Claude interact with desktop environments. Microsoft and others have supported Model Context Protocol, a standard way for agents and models to connect with tools and data sources.
The best tool design is boring in the right way. Each tool has a clear name, a clear input, a clear output, and a clear permission boundary.
Memory and context
Agents need two kinds of memory.
The first is task memory: what the agent is doing right now. Which files did it inspect? What did the user ask? What changed after the last tool call? Which step failed?
The second is longer-lived memory: preferences, prior decisions, project facts, customer context, or organizational rules. This memory can make agents feel much more useful, but it also raises privacy and correctness questions. Old memory can become stale. Wrong memory can quietly steer future work.
Good systems make memory inspectable and editable. If an agent remembers something important about you or your company, you should be able to see it and correct it.
Planning
Some agents plan explicitly. They write a short task list, complete each step, and revise the list as evidence arrives. Others plan implicitly inside the model. For serious work, explicit planning is often better because it gives the user and the system something to inspect.
A good plan is not a long ceremony. It is a control surface. It lets a person see whether the agent understood the task before it starts changing files, sending messages, or spending money.
Sandboxes
Agents that can run code or edit files need a controlled place to work.
That is why sandboxes matter. A sandbox can limit the files, network access, credentials, and commands available to the agent. OpenAI’s 2026 Agents SDK update made native sandbox execution a major feature, including a manifest for describing the agent’s workspace and mounting data from storage providers.
This is not just developer convenience. It is security architecture. Agents should be designed with prompt injection and data exfiltration in mind. If the model-generated code runs in a separate environment without broad credentials, one bad step is less likely to become a breach.
Approvals
Approvals are where human judgment enters the loop.
An agent may be allowed to read documents and draft a recommendation without asking. It may need approval before emailing a customer. It may be forbidden from changing account permissions. The same agent can have different authority in different contexts.
This is how mature agent systems will feel: not autonomous everywhere, but trusted in lanes.
Observability and evaluation
If a person cannot inspect what an agent did, the system is not ready for serious work.
Observability means traces, tool-call logs, intermediate outputs, costs, errors, safety events, and final decisions. Evaluation means testing the agent on realistic tasks before and after changes. Did it use the right sources? Did it ask for approval when required? Did it complete the task? Did it leak private data? Did it stop when uncertain?
Agents are software, but they are not deterministic software in the old sense. They need tests that measure behavior, not only functions that return exact outputs.
Multi-agent systems
Some tasks are better split between specialized agents. One agent researches. Another writes. Another checks citations. Another runs tests. Another reviews for policy.
This can help when roles are clear. It can also create overhead, duplicated work, and new failure paths. Multi-agent design is useful when specialization improves reliability or when parallel work saves time. It is theater when five agents are created because five sounds more advanced than one.
The real architecture question
The central question is not how clever the agent sounds. It is whether the system can answer:
- What can the agent see?
- What can the agent change?
- What does the agent know?
- What must the agent ask before doing?
- What record is left behind?
- What happens when it fails?
That is the difference between a demo and infrastructure.
