How To Build An AI Agent: The Framework, The Workflows, And What To Build

The businesses deploying AI agents this year and getting real results share one habit: they mapped the work before they touched the tools. The ones that build something that does not hold up almost always started with a model or a platform and worked backward toward a problem, instead of starting with a clearly defined job and working forward toward the architecture that solves it.

I am Madhuranjan Kumar, and every agent build I take on begins with one question: what job does this agent have, and which sub-agents need to exist to do it well? Answering that question on paper before writing a single instruction is the decision that separates agents that work reliably from agents that look like they should work but fall apart under real conditions.

An agent, at its structural core, perceives information from an environment, processes what it finds, and acts toward a defined goal without a human directing each individual step. In practice, the agent you experience from the outside as a single coherent thing is almost never one model doing all of that. It is a coordinated team of sub-agents, each responsible for a single job, passing results forward in a structure that produces the combined outcome you perceive. The logic mirrors the way a well-run team is structured. Assign one person to handle sales, operations, legal review, and product decisions simultaneously and performance on each task suffers. Divide the work across focused people with clear, narrow scopes and the whole team performs better. Agents work identically.

The building blocks that compose any agent are models that reason and decide, tools that let the agent act in the real world, knowledge and memory that give it access to relevant context across interactions, guardrails that keep behavior within defined bounds, and orchestration that connects the components and monitors their operation. You do not need to implement all of these on the first build. You do need to know which ones your use case requires before you begin, and that mapping is done before any configuration is opened.

Map the sub-agents before you write any instructions

Before a prompt is written, before a tool is wired, before any configuration file is opened, the first task is drawing the team on paper. Take your use case and decompose it into its component decisions. A customer inquiry agent is not one decision. It is a classification decision, a lookup decision, a reply generation decision, and an escalation decision. Each of those is a sub-agent with one input, one output, and one clearly bounded scope. The map of that team is what you draw first.

The reason the mapping comes before the instructions is that the architecture determines everything downstream. Collapsing two distinct decisions into one sub-agent creates a model that juggles two different cognitive tasks in a single pass and produces less consistent output on both. A classification sub-agent that also writes the reply conflates the question of what type this message is with the question of what a good response to it sounds like. Separate the two and each sub-agent does one thing well, tests cleanly against its specific job, and can be improved without touching any other part of the system.

For a medical billing office handling insurance claim inquiries, the map looks like this. Sub-agent one is the classifier, which reads each incoming message and assigns it to one of five defined categories: eligibility question, claim status question, denial appeal, payment inquiry, or escalation required. Sub-agent two is the policy lookup specialist, which takes the classified category and retrieves the accurate claim information or policy rules for that specific type from the claims management system. Sub-agent three is the reply writer, which takes the retrieved information and produces a clear, appropriately toned response. Sub-agent four is the escalation router, which handles anything the first three cannot confidently resolve and creates a ticket for a human to address. Each of these is a discrete, testable unit. Improving how the classifier handles ambiguous edge cases requires no changes to the reply writer. Updating the escalation criteria touches only the router. The map is what makes that independence possible.

Draw the team before you open any tool. The map is the plan, and everything built after it reflects the quality of the thinking that produced it.

Choose the simplest workflow that actually closes the loop

With the sub-agent team defined, the next decision is which workflow pattern connects them. Five patterns cover almost everything built in practice: prompt chaining, routing, parallelization, orchestration, and evaluator-optimizer loops. The rule I apply on every build is to reach for the simplest pattern that reliably gets from input to a resolved output. Unnecessary complexity in an agent architecture is a failure mode that shows up as maintenance cost, debugging time, and inconsistent behavior under edge cases you did not anticipate.

Prompt chaining is an assembly line where each sub-agent processes the previous one's output and passes it forward. This pattern solves the majority of real business agent problems. The billing office is a chaining problem: the classifier output feeds the policy lookup, the lookup output feeds the reply writer, and the reply either goes to the customer or routes to the escalation sub-agent. That is the complete workflow.

Routing reads each incoming input and sends it to the sub-agent built specifically for that type, rather than routing every input through every stage. A support agent handling five distinct inquiry categories does not need to run a routine payment question through the denial appeal specialist. The router reads the input first and sends it where it belongs. Routing is the right choice when your input types are distinct enough that a specialist meaningfully outperforms a generalist on each type.

Parallelization runs multiple sub-agents simultaneously on independent portions of the same task, or runs the same task through multiple sub-agents and aggregates the results for confidence. This is the right choice when task components are genuinely independent and sequential processing adds latency you cannot accept, or when a high-stakes output benefits from multiple independent attempts before a final result is committed.

Orchestration and evaluator-optimizer loops are the most autonomous and the most complex. An orchestrator spawns subtasks it cannot predict in advance, which is the right pattern when the number of steps required is unknown until the work is underway. An evaluator-optimizer loops output through a critic until it clears a defined quality bar. Both patterns add meaningful overhead and should not be chosen until the simpler patterns have been genuinely ruled out.

The billing office needs chaining and routing. Nothing beyond that. That architecture launches faster, produces more predictable output, and is far easier to debug and improve over time than an orchestration approach would be for the same problem.

Wire only the tools the agent genuinely needs on day one

Tools are what transform a language model from a text responder into a system that acts in the real world. Giving an agent the ability to look up a real account record, read a calendar, write a row to a spreadsheet, or send a message to a platform is the difference between an agent that answers questions conceptually and one that resolves actual work. The model context protocol from Anthropic standardized how tools connect to models, replacing the previous approach of writing custom integration code for each capability separately. The wiring overhead has dropped considerably as a result.

The error most builders make with tools is granting access to everything the agent might eventually need rather than only what it clearly needs on day one. Excess tool access creates two problems that compound each other. First, it increases the surface area for unintended behavior. A tool the agent does not need for routine tasks is still a tool it can accidentally invoke during an edge case, with consequences that are harder to anticipate and correct. Second, it increases the cognitive load on the model, because every available tool adds to the context the model must reason over when deciding what action to take at each step.

For the billing office, the day-one tool list is short. The policy lookup sub-agent needs read access to the claims management system to retrieve accurate records. The reply writer needs no external tool access because it generates output from the lookup result alone. The escalation router needs write access to the ticketing system to create escalation tickets when one is required. Three tools, each with exactly the permissions the sub-agent using it requires and nothing more. Write access to the claims system itself is not in scope on day one, because the agent has not yet earned the trust that would make that access appropriate. That trust is established through a monitored period where outputs are reviewed before the access is expanded.

Many of the most valuable tools for a business agent live in the CRM and website stack where customer records, transaction history, and communication threads are stored. Starting with read access to those systems and expanding permissions only after a monitored review period is the correct sequencing on every build.

Write a six-part prompt before you touch any configuration

The most important element of any agent build is the prompt, and the most reliable structure for a prompt that consistently produces the right behavior has six sections, each of which does a different and necessary job: role, task, input, output, constraints, and capabilities. Writing all six before any configuration file is opened forces decisions that catch problems before they reach a live user.

Role defines who the sub-agent is in functional terms, not in general terms. Not a helpful assistant, but a billing specialist with read access to the claims management system, operating under the applicable data handling requirements for that context, and authorized to retrieve and report information but not to modify any records. That specificity sets the frame through which the model reads everything that follows.

Task defines what the sub-agent does in this specific interaction. For the policy lookup sub-agent, the task is: given a classified inquiry category and a patient account identifier, retrieve the current claim status and the relevant policy information for that category from the claims system, and return a structured summary that the reply writer can use directly. Specific, narrow, and unambiguous.

Input defines what the sub-agent receives and in what format. Defining this prevents the sub-agent from trying to interpret ambiguous output from an upstream sub-agent in real time, which is where inconsistencies emerge at the seams between stages.

Output defines what the sub-agent produces and in what format. Consistent output format creates predictable handoffs between sub-agents and makes the full chain testable against real examples before anything goes live.

Constraints are the section most builders underweight, and the section that does the most work to prevent the failure modes that cause the most damage. The billing lookup sub-agent must never guess at a claim status when the record is ambiguous. It must never return information from one account when given an identifier for another. It must never modify a record under any circumstances. It must route to the escalation sub-agent when the lookup fails or returns no result. The constraints that feel most obvious in conversation are the ones most commonly omitted from prompts, and those omissions are exactly the gaps the agent exploits in the situations that matter most.

Capabilities defines which tools the sub-agent has access to, stated explicitly so the model's awareness of its own resources is clear and contained rather than implied.

The most important instruction in the prompt goes last. Language models weight recent text more heavily in their processing, so the constraint or requirement you most need the model to carry forward belongs at the end of the prompt, not buried in the middle where it gets attention-diluted by everything that follows.

For the billing office example, writing each sub-agent's full six-part prompt took roughly twenty minutes of focused work. After six weeks of live operation, the agent team was handling 74 percent of the 180 weekly insurance inquiries that previously required manual staff involvement, with no escalations attributed to the agent providing inaccurate policy information. The three billing coordinators who had been spending a combined twelve hours per week on routine inquiry handling moved that time to complex denial appeals and new patient intake, which are the tasks where their experience and judgment generate real value. At a fully loaded cost of thirty dollars per coordinator hour, the operational saving on that one task category runs to roughly one thousand and eighty dollars per month. The total build time across team mapping, workflow design, tool wiring, and six-part prompts for all four sub-agents was eleven working days.

If you want to find the right first agent for your own operation, start with the task that, if offloaded cleanly, would most noticeably free your team for the decisions that require real judgment. Most businesses find that task in the first ten minutes of the exercise. The high-volume follow-up work that flows from Meta ads or Google Ads lead forms is a common starting point, because the number of routine tasks triggered by each incoming lead is large, highly consistent, and structured in exactly the way that makes agent workflows reliable from day one.