I’ve spent the last few months deep in agent-based architectures. Specialized agents, skills, contracts, handoffs, human gates, separated contexts, MCP tools, reviewers — I’ve worked with all of it. Different ways of orchestrating the whole thing too.

After all that, I still think we need agents. But I’m less convinced now that we need as many as some architectures are starting to suggest. That distinction matters because there is a pattern in software architecture we keep repeating: we start simple, discover the limits, and add components to compensate. The trouble comes when those compensations pile up and the architecture becomes more sophisticated than the problem actually requires.

Agents and Skills are hitting exactly that point right now.

Capability does not imply responsibility

A skill and an agent aren’t the same thing, even when we use them to solve similar problems.

A skill is mostly about capability — how to do a task, which tool to use, what steps to follow, what rules apply. An agent can mean something different: it represents a responsibility inside the system.

Tool        → With what
Skill       → How
Agent       → Who
Workflow    → When

I’m not claiming this is a formal taxonomy, but it’s useful for making architectural decisions. MCP sits one level lower in this picture: it is a protocol for exposing capabilities such as tools, resources, and prompts, not a synonym for a tool itself.

GitHub’s take on this is interesting. They describe Agent Skills as folders of instructions, scripts, and resources that Copilot can load when needed. Custom agents, by contrast, are specialized versions of Copilot with their own prompts, tool restrictions, and optional MCP servers. That distinction works because it separates reusable capability from an execution boundary — each with its own context and responsibility. GitHub Docs: Agent Skills · GitHub Docs: Custom agents and sub-agent orchestration

A skill can be perfect at reviewing AL code, but that doesn’t mean it should own the decision about what to do with the results. You can have an excellent compilation skill without needing a dedicated Compile Agent. An agent is not justified simply because it can do something different; it becomes useful when we need a distinct owner for the outcome.

Capability and responsibility are different things.

When Skills create a monolith

The first problem shows up when you keep one general-purpose agent and just keep adding more skills around it.

At first glance, it looks really modular. There’s an architecture skill, another for AL development, one for tests, one for code review, maybe one for documentation.

But the same agent still has to interpret the requirement, decide which skill to use at every turn, do the design, implement it, interpret the results, correct itself, review its own work, and figure out when it’s done.

You’ve distributed capabilities, but responsibility stays completely centralized.

That’s what I call the Agentic Monolith.

Not because skills themselves are wrong, but because you end up with something that knows too much, decides too much, and carries too much context. From the outside it looks modular. Inside, all the decision-making is still in one place.

Skills alone don’t solve this. There’s actually a second pattern: skills whose contracts get so broad they start looking like agents themselves, sometimes calling other skills. At that point you’re not simplifying anymore. You’re nesting monoliths.

When Agents create bureaucracy

The opposite extreme is making every step in the process its own independent agent.

You could have a Requirement Agent, Specification Agent, Architecture Agent, Planning Agent, Developer Agent, Test Agent, Reviewer Agent, and maybe another one supervising all of them. On paper it’s attractive. Every component has a clear role and you can draw a nice diagram. But every new boundary also costs something.

You need to provide context, transfer decisions, maintain state, interpret handoffs, coordinate work. Information gets repeated between agents. Every context switch is another chance to lose something. That also means more inference calls and more tokens. The system looks smarter because it has more actors. What you’ve actually increased is coordination overhead.

That’s the other extreme: Agentic Bureaucracy.

What ALDC Graph taught me

ALDC Graph was deliberately ambitious. I wanted to push further on ideas already present in ALDC: separate responsibilities, specialized agents, explicit workflow state, graph-based orchestration, and parallel work where it made sense.

The experiment worked, and that is important. On complex problems, Graph could produce very good results and, in some cases, the quality of the solution was better than with the standard ALDC flow. But the improvement came with a real price: substantially more context, more agent coordination, more repeated information, more state management, and roughly twice the token cost in the tests that mattered most to me.

That changed the question. It was no longer whether a graph-based multi-agent architecture could work. It clearly could. The question was whether the quality gain justified maintaining a separate architecture with that much coordination overhead and that many additional failure modes around state, handoffs, synchronization, and context transfer.

For me, the answer was no. So I stopped ALDC Graph as a separate architectural direction and started extracting the parts that were genuinely useful back into canonical ALDC: improvements to the Spec Agent, lessons from the plugin model and different execution surfaces, ideas for the Doctor, better contracts, and practical experience with parallelism and context isolation.

That was the useful outcome. The experiment improved the system, but the entire experimental architecture did not need to survive.

Experiments should leave capabilities behind, not complexity.

A recent observation from Uncle Bob points in the same direction

A few days ago I came across something from Robert C. Martin — Uncle Bob — that grabbed me because I recognized my own experience in it.

Martin was working on Swarm Forge, a framework for coordinating multiple agents through roles, worktrees, protocols, and explicit orchestration. He’d been talking about deterministic constraints and tests around AI-generated code. More recently, he started asking how much of that scaffolding was still necessary as models got better.

On September 14, 2026, he noted that since stopping his harness, token consumption had dropped dramatically, and he described the harness itself as massively inefficient. That is his observation. My interpretation is what makes it relevant here: part of the scaffolding we build around models can become obsolete as the models improve. Robert C. Martin on X, September 14, 2026

Over the last few years we’ve built a lot of mechanisms to work around model limitations. Model doesn’t plan well? Add a planner. Want a second opinion? Add a reviewer. Process is unstable? Add states and gates. Model needs specialized knowledge? Add skills. Task too big? Add subagents.

Any of that can make sense. The problem starts when a temporary model limitation becomes a permanent architectural choice.

Never turn the limitations of the current model into permanent architecture.

Delegating is not the same as invoking

None of this means specialized agents are dead. I think it means the opposite: we should be pickier about when an agent is actually justified.

One of the clearest distinctions for me is between invoking a capability and delegating a responsibility.

When a Developer uses a skill to compile a project, the Developer is still responsible for the result. The skill just provides a capability the Developer needs.

When that Developer hands an implementation to a Reviewer and asks it to determine whether criteria have been met, that’s different. The Reviewer may use multiple skills, but that’s not why it exists. It exists because we want an independent responsibility, a separate context, and the power to return something like CHANGES_REQUIRED.

That’s delegation. And that’s where I see real architectural value.

Context separation can be another good reason. A specialized agent can analyze a task without carrying all the reasoning and decisions from whoever came before it. That independence is especially useful for review, validation, or research.

But separated context isn’t free. Every new agent still needs enough information to understand its work — goals, constraints, evidence, previous decisions.

So now I try to ask a different question than just whether a task can become an agent.

The question is whether that responsibility really deserves its own context.

Agents and Skills are not competitors

The title Agents vs Skills is deliberately misleading, actually.

I don’t think we need to choose. The best systems will probably be compositional: a small number of agents with clear responsibilities, using reusable skills, connected to tools through well-defined interfaces.

Responsibility
      ↓
    Agent
      ↓
Capabilities
      ↓
    Skills
      ↓
 Tools / MCP capabilities
      ↓
Verification

The same skill can be useful to multiple agents. But a responsibility should have one clear owner.

It also keeps us from another common mistake: turning purely mechanical operations into agents just because the platform lets us.

If something can be solved deterministically with a tool, it probably doesn’t need inference. If a capability can be packaged as a reusable skill, it probably doesn’t need its own independent actor either.

An agent makes sense when it brings something genuinely worth that boundary: independent judgment, differentiated responsibility, context isolation, specific tools or permissions, the ability to alter the workflow, or enough parallelism to justify the extra cost.

Between the monolith and the bureaucracy

I’m starting to see two risks in agentic architecture that are becoming easy to spot.

One extreme is the Agentic Monolith: one agent collects all responsibilities and keeps using more and more skills.

The other is Agentic Bureaucracy: every activity becomes an agent and the system spends significant resources just coordinating with itself.

The answer isn’t finding a number in the middle. It’s finding the minimum number of boundaries required to represent responsibilities that genuinely deserve independence.

And that architecture shouldn’t be locked in stone either.

As models improve, we need to keep asking which parts still matter and which were just compensating for limits that don’t exist anymore.

How much architecture does this model really need to solve this problem reliably?

That shift in the question is important. We’re not trying to build the most agentic system possible; we’re trying to build the simplest system that preserves enough responsibility, verifiability, and quality. That sounds much more like software engineering than prompt engineering.

My working rule is simple: if something knows how to do a task, it can probably be a skill. If something has to answer for an outcome, it might deserve to be an agent. And if the model can already solve the problem reliably without that extra layer, the best move may be not to add it.

My experience with ALDC Graph and Robert C. Martin’s recent observation come from different projects, but they point in the same direction: models are evolving, so the architecture around them must remain open to simplification. Good engineering is not only knowing when to add a boundary. It is also knowing when that boundary is no longer earning its cost.