The Five Pillars of Agentic AI Architecture: How Modern AI Agents Are Actually Built

For most of the last few years, "AI" meant a chat window. You typed, it answered, and the conversation ended there. That era is closing. The systems drawing serious attention now don't just talk; they plan a task, write the code, call the tools, and carry the work through with very little hand-holding. We've stopped building chatbots and started building digital coworkers.

But here's what gets lost in the excitement: an agent isn't a smarter model. The underlying language model is much the same. What turns a model into an agent is a layer of structure wrapped around it: a set of conventions that tell it how to behave, what it knows, what it can reach, and how it coordinates with other agents.

I've spent the last couple of years building these systems hands-on, and underneath nearly every capable agent you'll find the same five architectural pillars doing the work. Understanding them is the difference between treating agentic AI as magic and treating it as engineering. Here they are, in the order they tend to matter.

1. AGENTS.md: the project's instruction layer

The first pillar is almost disappointingly simple: a plain markdown file named AGENTS.md, sitting at the root of a project. The agent reads it every time it starts work in that project.

Think of it as a README written for a machine instead of a person. A README tells a new human developer how the project works. AGENTS.md tells the agent the same thing, and then holds it to those rules. In practice it carries three kinds of context:

• Setup commands: how to prepare the environment, and which tests to run before committing.
• Coding conventions: the style, patterns, and architecture this codebase actually uses.
• Workflow rules: the housekeeping, like how a pull-request title should be formatted.

What makes it genuinely useful is that these files nest. You can keep broad rules at the project root and more specific ones deeper in a sub-folder, and the closer file wins where they conflict. A monorepo can have one set of house rules at the top and tighter, local rules for each service, exactly how you'd brief a team.

AGENTS.md was introduced by OpenAI and is now a founding project of the Agentic AI Foundation (AAIF), the Linux Foundation body formed in December 2025 to keep these standards open and vendor-neutral. A few platforms use their own filename (Anthropic's Claude, for instance, reads CLAUDE.md), but the idea is identical, and the open standard is converging.

2. Agent Skills: modular task expertise

If AGENTS.md tells an agent how this project works, the second pillar tells it how to do a particular kind of job.

The problem Skills solve is a real constraint, not a theoretical one. An agent has a finite context window: its working memory. Cram every possible instruction into it at once and you "clog" that memory with things irrelevant to the task in front of it, which makes the agent slower and worse. It's like handing someone every manual in the building when all they asked was how to make a slide deck.

An Agent Skill is a small folder: a SKILL.md file plus any scripts or resources the task needs. The SKILL.md opens with a short description of when to use it, such as "use this when the user wants to build a PowerPoint deck." The agent reads only those descriptions by default. When a request matches one, it pulls that skill into context; when it doesn't, the skill stays out of the way. Knowledge becomes modular and load-on-demand, and the agent's attention stays on the job. Like AGENTS.md, Agent Skills are an open standard implemented across multiple platforms.

3. Model Context Protocol (MCP): connecting to the world

An agent that can only reason is a clever box that can't reach anything. To be useful, it has to touch the outside world: query a database, hit an API, file a ticket, pull a record from a SaaS tool. That's the third pillar.

The old way to do this was a custom connector for every single tool. Ten tools meant ten bespoke integrations, each one a thing to build and maintain, a fragmented mess that didn't scale. The Model Context Protocol (MCP) replaces that with one open standard. An MCP server wraps a tool or data source in a consistent interface, and any agent that "speaks" MCP can use it, with no custom glue per tool.

The practical effect: if your agent needs to read a page from Notion or generate a payment link in Stripe, it speaks to the MCP server in the same standardized way it speaks to everything else, and the server handles the messy, service-specific API calls underneath. MCP originated at Anthropic, has become the de-facto standard for tool connectivity (with tens of thousands of published servers), and was donated to the Agentic AI Foundation in late 2025 to keep it neutral and open.

4. A2A: agent-to-agent communication

Once you have more than one capable agent, they need to work together. The fourth pillar is the protocol for that conversation.

The natural pattern in any real organization is specialization: one agent is good at procurement, another at finance, another at legal review. In a real workflow, one of them will need to hand a task to another. Without a standard, every handoff is a custom integration and coordination falls apart. A2A (Agent-to-Agent), originally from Google, is the open protocol that fixes this. Every agent publishes an agent card: a small, discoverable description of what it does and how to interact with it. Other agents read the card and know how to delegate.

A clean example: a procurement agent negotiates a supplier contract but isn't allowed to approve the spend. It reads the finance agent's agent card, understands how to hand off, and passes the contract over for sign-off, with no human stitching the two together. A2A was donated to the Linux Foundation in mid-2025 and now has support from 150-plus organizations. (Worth noting, since the two are often confused: MCP connects agents to tools; A2A connects agents to each other. They're complementary, and they're governed as separate open projects.)

5. Subagents: parallelism and context management

The final pillar is what lets a single agent take on work that's simply too big for one mind to hold: spawning subagents, child agents that handle a slice of the task in their own fresh context.

Two situations call for this. The first is sheer size: ask an agent to review a codebase of thousands of files and loading them all at once would blow out its context window. Instead, the parent spawns subagents, each reading a manageable batch (say 500 files) and returning only a summary. The second is speed: if twenty independent checks need to run, twenty subagents can run them at once, and a job that was sequential becomes roughly twenty times faster.

The discipline that makes this work is context isolation. Each subagent works in its own clean context and reports back only the result, not its entire scratch-work, which keeps the parent's context uncluttered and focused. Of the five pillars, subagents are the one without a single formal standard document yet, but the pattern is so useful that it's implemented almost identically across every serious agentic system.

Putting it together: a worked example

Pillars are easier to trust when you can see them carrying weight. Picture a mid-sized e-commerce company, call it Northwind, that wants to automate the grind of restocking inventory. Here's how the five pillars assemble into a working system rather than a demo.

Northwind's engineers drop an AGENTS.md at the root of the automation project (pillar 1): which internal systems are source-of-truth, how to format every log entry, and a hard rule that no purchase order goes out without human sign-off above a spending threshold. Every agent in the project inherits that brief.

The reordering agent is given an Agent Skill (pillar 2) for demand forecasting: a SKILL.md plus the scripts that turn sales history into a reorder recommendation. It loads only when a restock decision is actually being made, so the agent isn't carrying forecasting math around while it does everything else.

To act, the agent reaches its tools over MCP (pillar 3): one server for the inventory database, one for the supplier ordering API, one for the accounting system. Swapping a supplier later means standing up one new MCP server, not rewriting the agent.

When a reorder is ready, the reordering agent uses A2A (pillar 4) to hand the draft purchase order to a separate finance agent for budget approval, reading its agent card to know exactly how to delegate: the procurement-to-finance handoff, made real.

And on the nightly full-catalogue review, the parent agent spawns subagents (pillar 5) to scan inventory across thousands of SKUs in parallel batches, each returning a short summary, so the whole sweep finishes in minutes instead of hours and the parent's context never overflows.

No single piece is exotic. The capability comes from the composition, which is the whole point of treating this as architecture.

What this looks like in my own work

I didn't arrive at these five pillars from a whitepaper. I arrived at them by building. NEXUS, a multi-agent software-delivery platform I built, runs a team of specialized agents (Orion, Scribe, Reviewer, Scout, Herald) that coordinate over an event-driven backbone with shared graph memory: A2A-style delegation and subagent parallelism doing exactly what's described above, against the real problem of shipping code. And Anima, an open-source operating system for running a company on agents, leans hard on AGENTS.md-style instruction layers and MCP for tool connectivity, with a human proxy holding the keys to anything that matters.

That last detail is the one I'd underline. I spent eighteen years in safety-critical control systems, where a process that fails in production isn't a disappointment; it's a hazard. That background makes me wary of autonomous systems that act without oversight, and it's why, in everything I build, the human stays in control of the decisions that count, every action is logged, and the system is designed to fail safely. The five pillars give an agent capability. The discipline around them is what makes that capability trustworthy.

Conclusion

Strip away the hype and frontier AI agents rest on five understandable pillars. AGENTS.md sets the rules of the project. Agent Skills make expertise modular and load-on-demand. MCP standardizes the connection to tools and data. A2A lets specialized agents collaborate. Subagents provide parallelism and keep context clean. None of them is magic. Each is a piece of engineering, and together they're what move AI from a chat window to a system that does real work.

If you're trying to figure out where agents fit in your own operation, and just as importantly how to adopt them without losing control of what matters, that's exactly the seam I work in.