How to Design an Agentic System

Whether you want an executive assistant, a software factory, or an agentic organization

What Problem(s) Do You Want to Solve?

The most useful agentic systems start with a clear understanding of the problem(s) that they are designed to solve. Are you looking to build a software factory to write, test and deploy your code, an assistant to help you with your everyday tasks or a business process engine to automate workflows across your organization? Each one might require a different approach.

The goal of this article is to break down the key design decisions so you can understand your needs, evaluate the options and then decide whether to build, use (OSS) and/or buy.

Please note, all of this is specifically for internal tooling - not scaled, hardened customer facing systems. Those are fascinating, but I’ll write about those once I’ve built one myself!

The Elements of an Agentic System

There are lots of ways of decomposing an agentic system. I find it useful when designing a system to look at it through five lenses:

• Workflow - How the system determines the steps to perform to complete a repeatable unit of work (delivering software, creating content, managing a sales pipeline, etc)

• Co-ordination - This is the plumbing to make sure that your agents actually do what they’re supposed to - mostly durable execution and clean-up for the mistakes the agents will invariably make.

• Compounding/memory - This is how you ensure that your agentic system gets better over time - regularly extracting context from sessions and persisting them in a useful way.

• Tool use - This is how your agentic system operates in the world - engaging with web pages, emails, calendars, chat apps and systems of record to allow it to perform work.

• Security - How you mitigate risks like prompt injection to minimize the likelihood and the impact of any exploit.

In addition, you need to think about how to move from augmentation to automation, verification (and the Ralph loop), and whether you want an assistant or an organization.

Workflow Design

If you have any non-trivial piece of work that you want an agent to engage with, someone is going to be coming up with a workflow to decompose the work into the steps required to complete it. For any given piece of work, those pipelines can be categorized as emergent, fixed or configurable.

• Emergent. Give the agent a task, let it figure out how to perform it. This is the default “chat bot” mode, but it’s also a good mode for discovery - for performing work that you haven’t had the time or knowledge to codify into a repeatable set of steps. For one off tasks and simple work, emergent workflows might work well enough.

• Fixed. You’ve learned the steps, codified them, and now the pipeline runs the same way every time. If you have a small number of workflows to support and they don’t have too many steps, you can hard code your pipeline into your system to make sure (for example) that every project gets specified, planned, decomposed, coded, tested and deployed.

• Configurable. If you think about it for a couple of minutes you’ll realize that what you’re doing here is describing pipelines/workflows and that it probably makes sense build or use some kind of pipeline/workflow system so you can extract the configuration of a workflow from code into a domain specific language, making it much easier to create, modify and reason about your workflows.

In practice, you’ll probably use emergent flows for one off or low stakes tasks and over time you’ll codify more of your other workflows into configurable pipelines. If you’d like to dig deeper, I put together a piece on workflow configuration for agentic systems with some more details.

Coordination

Orchestration is workflow. Coordination is cleanup. This is the unglamorous part: making sure agents actually finish what they started, and dealing with the mess when they don’t.

Agents fail in ways that are different from traditional software. They don’t throw clean exceptions. They hang mid-task. They leave stale branches that should have been deleted. They forget to merge completed work. They get confused by their own context and need to be force-restarted. They make partial progress that’s hard to distinguish from no progress at all. If you’ve run more than a few agents in parallel, you’ve experienced all of this.

You can build coordination infrastructure yourself using tools like Temporal or Restate for durable execution. But the hard part isn’t the tooling. It’s discovering which error patterns your specific agents actually hit. That comes from experimentation. You’ll find your own set of failure modes, and you’ll build your own cleanup scripts, and they’ll be different from everyone else’s because the failure surface depends on what your agents are doing.

Compounding and Memory

The most important reason to start building agentic systems today is so that you can start to extract and document your taste, decompose your workflows and persist your context. Good looks different at every company and without that context, the smartest foundation model will still fail to ship deliverables that meet your needs.

Two months ago, my research agent Elise cited a study without checking the sample size. I corrected her. She wrote the correction into her working memory. She hasn’t made that mistake since. That’s the compounding loop: the system learns from a failure, persists the lesson, and applies it to future work. Over time, those corrections accumulate into something that looks a lot like judgment.

Compounding happens at three layers. Agent-level: an individual agent learns from its own mistakes and preferences. System-level: the factory itself improves, as pipeline metrics identify failure patterns and workflows get tightened. Human-level: the people using the system get better at specifying intent. The most effective systems compound on all three simultaneously.

The mechanism is memory. An agent without memory is a tool. An agent with memory is a colleague. But memory requires active management. Too little and the agent repeats the same mistakes every session. Too much and it drowns in stale context, spending tokens on corrections that no longer apply to a problem it solved weeks ago.

Gas Town’s Beads system handles this with semantic decay: completed tasks get summarized with the reasoning preserved, then archived. The stale details go away. The lessons stay. Manus, the Singapore-based agent platform, found that typical tasks require around 50 tool calls spanning hundreds of conversational turns. They refactored their context architecture five times in the first year. That’s what it looks like when a team takes memory management seriously.

The practical pattern: write everything during a session. At the end, trim to essentials. Update what’s changed, remove what’s obsolete, compress what’s redundant. Treat memory like code. It needs refactoring.

Different kinds of state need different storage. Git for configuration and pipeline definitions (versioned, auditable, mergeable). Perhaps a relational database for structured operational data like tasks, contacts, and customers. Vector stores for semantic similarity when you need to find things that are conceptually close, not just textually matching. Graph based systems when graph traversal is an important retrieval pattern. Your system will likely use several of these. The choice isn’t “where do I store things.” It’s “what properties does this state need?” If you’d like to go deeper, here are some thoughts on compounding, memory and persistence.

Tool Use

This is how your agent operates in the world: reading emails, updating calendars, querying databases, creating documents, calling APIs.

You start by prompting. You describe what you want the agent to do, and it figures out how to interact with whatever tools are already available. For simple tasks, this is enough.

When you need your agent to reach external systems, you have two options with different tradeoffs.

MCP (Model Context Protocol) is the standard for connecting agents to external tools and data: 97 million monthly SDK downloads in its first year, first-class support across Claude, ChatGPT, Cursor, Gemini, and VS Code. You install an MCP server, your agent gains new capabilities. It’s fast to set up, and for data sources where someone else has already built the integration (Slack, GitHub, databases, web scraping), it gets you connected quickly.

Direct API integrations take more work to build, but you control them completely. They’re auditable, testable, and predictable. You can see exactly what’s being called, with what parameters, and handle errors explicitly. For anything you care about owning (your billing system, your CRM, your deployment pipeline), direct integrations are the stronger choice.

These aren’t sequential steps. You’ll use both in the same system. MCP for quick access to data sources where the integration already exists. Direct APIs for the integrations that matter most to your business. The deciding factor is how much control and visibility you need.

The pattern most production systems converge on for either approach is deterministic code wrapping non-deterministic model calls. A script with clear inputs and outputs that calls the model where judgment is needed and uses plain code for everything else. The model decides what to say in the email. The script handles authentication, formatting, error handling, and sending. You get the flexibility of AI where it matters and the reliability of code everywhere else.

Security

The moment your agent reads untrusted input, building a trustworthy system gets very hard, very quickly.The primary threat is prompt injection: crafted input that hijacks your agent’s behavior. A malicious instruction hidden in a GitHub issue can extract secrets from your agent’s environment. A Palo Alto Networks study showed that indirect prompt injection can poison an agent’s long-term memory through a link in an email. The agent includes attacker instructions in its session summary, then silently exfiltrates user data in every subsequent session with no visible malicious behavior during the initial attack.

If your agent has memory, the attack surface compounds. The Echoleak incident demonstrated this: a prompt hidden in an email caused an agent to leak private information from prior conversations because it treated the new prompt and old memories as the same context.

Obsidian Security found that 90% of enterprise AI agents are over-permissioned, holding 10x more privileges than required. Agents move 16x more data than human users. The combination of over-permissioning and prompt injection is where the real risk lives.

The defenses are the same ones that work in traditional security, applied to a new surface: minimize permissions, isolate environments, validate inputs, treat all external content as untrusted, and never let an agent mark its own homework on security-sensitive operations. If you’d like to dig deeper, I wrote a piece on prompt injection and the trust boundary. But understand, this is not a solved problem.

Augmentation to Automation

Every agentic system sits somewhere on a spectrum. On one end: augmentation. The agent drafts, you review. The agent suggests, you accept or reject. The agent does the first 80%, you do the last 20%.

On the other end: automation. The agent acts, verifies its own work, and ships the result. StrongDM operates here: no human-written code, no human code review. Humans define intent. Agents handle everything else.

Most systems sit somewhere in between. Spotify’s Honk writes code autonomously and submits PRs, but an engineer reviews before merge. Coinbase went from 8-day ticket-to-PR cycles to 12 minutes, with 5% of PRs fully autonomous and the rest human-reviewed.

You can start anywhere on this spectrum. People download Open Claw and let it manage their personal workflow without a structured augmentation phase. That works because the cost of a mistake is low: a bad calendar entry or a poorly drafted message you will probably catch before sending.

The rate at which you should move toward automation depends on one question: what happens when the agent gets it wrong? A bad code suggestion caught in review costs five minutes. A bad email sent to a client costs a relationship. AWS learned this the hard way: a 13-hour outage after their Kiro agent deleted and recreated a production environment.

Three levers move you along the spectrum: codification (defining the workflow so it runs the same way every time), verification (building infrastructure that checks whether the output is good enough), and governance (setting clear boundaries on what the agent can and cannot do). The more you invest in each, the more safely you can grant autonomy.

It’s also critical to see all of the input you provide as RLHF. If you just fix the agents work without having the agent review the feedback and use it to improve its context, your system is not going to improve. I like Geoffrey Huntleys framing - you start in the loop, eventually you move to being “on the loop” - keeping an eye on the outputs and the observability data so that you’re not blocking the delivery of work but you’re not completely abdicating responsibility for the quality of the system.

METR ran a randomized controlled trial and found that ad hoc AI use slowed experienced developers by 19%, despite their belief it saved 24%. Coinbase’s structured approach cut 8-day cycles to 12 minutes. The gap between those results is deliberate design, not a better model.

Verification

If you can define what “good” looks like, even if you don’t have a well decomposed workflow or great context, you can just use a Ralph loop to iterate towards the verifiable reward. Whether you’re looking to ship code that passes the test suite or to improve the performance or a library, it’s a powerful mechanism to allow agents to keep working on something until they get it right.

An agent attempts something. A separate process checks the result. If it fails, the agent iterates. If it passes, the output moves forward. This is a powerful technique for improving quality. It works for code (tests pass, CI green), for data extraction (schema validates, values in range), for content (fact-checks clear, style scores above threshold). It is not specific to any one domain. It is also not required for every system. An executive assistant that drafts your emails doesn’t need a formal verification loop. The Ralph Loop is a technique you apply when (a) you can define clearly what good looks like and (b) it’s valuable enough to be worth burning tokens to keep trying until the agent gets it right.

The key constraint: the generator and the verifier must be different processes. An agent cannot mark its own homework. Stripe limits agents to two CI iterations before escalating to a human. Superpowers requires TDD before any code generation begins.

Verification is a design choice, not a property of the domain. Code happens to have rich pre-existing verification tooling: compilers, test suites, linters. But you can write code with zero verification. Conversely, you could build sophisticated verification for prose: style checkers, fact verification, voice matching. The question isn’t “is my domain verifiable?” It’s “how much am I willing to invest in verification infrastructure?”

That investment compounds. Devin, after 18 months of iteration, now merges 67% of its PRs versus 34% a year ago. 4x faster and 2x more efficient. The improvement didn’t come from a better model alone. It came from tightening the verification loop. And a counterpoint worth holding: Jellyfish’s analysis of 20 million PRs found that AI-coauthored PRs have approximately 1.7x more issues than human-only PRs. Scale without verification doesn’t just fail. It compounds failures. I put together a backing piece on verification which digs in a little deeper.

An Assistant or an Organization?

There’s a design decision that sits above everything else in this article: are you building a single agent or a team of them?

A single-agent system is one agent, one context, one set of capabilities. Open Claw manages your personal workflow: calendar, email, tasks, research. One agent handles everything. Simple to build, simple to reason about, and effective for personal use or narrow organizational tasks.

A multi-agent organization is different. Peter HQ has Morgan running operations, Elise directing research, Sloane managing engineering and Kira handling life management. Each agent owns a distinct domain with distinct knowledge and distinct judgment. Morgan doesn’t give health advice. Kira doesn’t prioritize work tasks.

“Multi-agent” is a term that conflates at least four different things. Same agent processing different inputs in parallel (that’s scaling). Same model with different prompts (that’s role assignment). Different models for different tasks (that’s routing). Fully differentiated agents with different knowledge, personality, and scope (that’s an organization). The first three are infrastructure decisions. The fourth is an identity decision.

If you build an organization, you’ll face a naming question. You can name agents descriptively: CEO Bot, QA Agent, Research Assistant. Or you can give them personalities: Morgan, Elise, Sloane. The naming choice affects how humans interact with them more than you’d expect. If you’d like to dig deeper, I wrote a piece on agent personality and naming.

Build or Buy?

Once you’ve decided the kind of system you want to use, the next question is build vs use (OSS) vs buy. If you can find something that meets all of your needs, you’re going to save time not having to build from scratch, but the risk is that you’re learning to use someone else’s system, not your own.

My personal take is that right now I will build, but build on primitives that are likely to persist. We are early on the technology adoption lifecycle. This is innovator and early adopter territory. The tooling landscape is churning fast. New frameworks launch weekly. Last quarter’s consensus pick is this quarter’s cautionary tale. Picking winners above the primitive layer is a losing bet right now.

The primitives that are likely to persist: a foundation model (I use Claude Code to access Opus and Sonnet, but you should plan for multiple providers, both for council-of-elders style verification and for business continuity if any one vendor falls behind), a relational database (Postgres), version control (git), and a durable execution framework (Temporal, Inngest, Restate).

Why build on these rather than adopt a higher-level platform?

• The orchestration and memory systems are straightforward to build and critical to tune for your specific use cases. A generic orchestrator makes generic decisions. Your system needs to know your domain, your quality bar, your failure modes. That tuning is the work. If you outsource it, you outsource the learning.

• Building teaches you how these systems actually work. At this stage of the technology, that understanding is more valuable than any time you save by adopting a framework. When patterns stabilize (likely late 2026 or beyond), you’ll evaluate platforms from a position of knowledge rather than hope.

• You skip the hard vendor evaluation problem. When there are no clear winners, the cost of evaluating, integrating, and migrating between vendors often exceeds the cost of building.

That said, point solutions can still accelerate time to value. A QA agent from a third party plugged into your CI loop, a document extraction service for a well-defined input format: if it solves a narrow problem well and doesn’t lock you in, use it.

The key insight: expect to throw away the implementation. Build with that assumption. What you keep: telemetry, context, institutional learnings, both human and agent. What you throw away: the specific orchestration code, the glue, the wiring. This is why Postgres and git matter as substrates. Your valuable state survives the rewrite.

Revisit this position quarterly. The market moves fast enough that the right answer in Q2 2026 may be wrong by Q4.

If you’re not an innovator or early adopter in AI, there’s a legitimate alternative: wait. The patterns are emerging but not yet settled. Adopting agentic systems today means accepting real ambiguity and investing significant time in learning. If that’s not your competitive advantage, you can skip the thrashing and adopt once the tooling matures.

What are you using to build your agentic systems? Let me know - I’d love to compare notes!