Earned Complexity

Building an AI agent now takes an afternoon. Give it a name and instructions, connect a few tools, and it can research topics, summarize documents, or triage email.

So you build another. One for research, one for analysis, one for writing, and a coordinator to manage them. Before long, a simple workflow looks like a small org chart.

It looks impressive. Is it actually better?

Being able to create more agents doesn’t mean you need them.

At Skyline Dev Labs, we think AI agent systems should earn their complexity. Every extra agent or coordination layer should solve a problem you can observe, explain, and measure. That starts with one agent.

Can one agent do the job?

Say you’re building a research assistant that tracks your industry. The goal: find important news, explain why it matters, and send a summary every morning.

One agent can probably handle all of it. It pulls sources, filters noise, summarizes what matters, and writes the report. Before you split that work across specialists, ask: can one agent produce this outcome consistently?

To answer that, write an operating contract before you design anything elaborate. What triggers the run? Which sources can it use? What counts as important? What goes in the report? How will you know it worked?

Then decide how it should fail. If a source is down, does it continue with partial evidence or stop? If two sources disagree, does it judge or ask for review? If nothing important happened, does it send an empty report instead of inventing significance?

Those answers decide whether anyone can trust the system. The first agent isn’t just a prototype. It’s how you find out what the workflow really requires.

Every agent you add has a price

Now suppose the single agent works reasonably well, and you split it into three: one finds news, one judges relevance, one writes the report.

Each agent has a narrower job. The system has a bigger one. The finder has to pass enough context to the judge. The judge has to keep its reasoning. The writer has to separate verified facts from interpretation. And something has to coordinate the run, handle failures, and decide when it’s done.

Here’s how that goes wrong. The finder flags a promotional press release as an industry breakthrough. The judge accepts it. The writer turns it into a confident executive summary. Every agent did its assigned job, and the result is still wrong.

More agents can spread out the work. They can also spread out the mistakes. Specialization pays off only when its gains beat the added coordination and failure costs, which is why agent count says little about how good an architecture is.

When the second agent earns its place

Add an agent when the current workflow shows a specific limit that separating the work would fix. A few good reasons:

• Speed. Research eats most of the run time, and analysis can’t start until it finishes. Parallel research workers could help.
• Quality. The agent keeps mixing up finding information with judging its importance. Separate roles, with evidence passed explicitly between them, could improve the output.
• Permissions. One task needs broad access to outside sources while another touches sensitive internal data. Splitting them can draw clearer boundaries, as long as the underlying system enforces them.

Many problems don’t need another agent at all. A better tool, a clearer instruction, a validation rule, or a better data structure often fixes it with far less complexity. Badly formatted reports call for an output schema, not a formatting agent. Repeated fetches call for caching, not a memory agent. If the agent can’t tell whether an article is recent, check the date in code instead of adding another model.

Agentic AI makes it tempting to solve every problem by adding another intelligent participant. Good architecture means knowing when not to.

Talking isn’t coordinating

Once you truly need several agents, the hard part becomes how they work together.

Many demos have agents chatting in a shared thread, assigning tasks and replying to each other. That’s a nice interface for a human supervisor. It isn’t enough to run a business process.

Each handoff needs a contract. The receiving agent should know what task it owns, what evidence it can rely on, what has already been decided, which tools it may use, and what done looks like.

The system also has to track state. Is a task waiting, running, blocked, done, or awaiting approval? What happens if an agent fails halfway? Can you retry without repeating actions?

This matters most once agents act on the outside world. An agent writing a summary and an agent emailing that summary to customers carry very different risks. The second needs authorization, approval, and protection against sending twice.

Agents being able to talk is a capability. Coordinating them safely is an architecture job.

Measure before you scale

How do you know a bigger team is worth it? Test the workflow before and after you specialize.

Start with a baseline. Record how often the single agent gets the task right, how long it takes, what it costs, how often a person steps in, and which failures repeat.

Then make the smallest change that targets one specific limit. If research is slow, try parallel workers. If interpretation is inconsistent, try a separate evaluation step. If evidence is weak, fix source verification before you touch the agent count. Compare results on the same set of representative tasks.

A design that improves accuracy but triples cost might be right for a high-stakes workflow and wrong for a daily digest. It depends on what failure costs you and what better performance is worth.

Good architecture should also let you remove complexity. If two agents do better as one, merging them is progress. The point of evaluation isn’t to defend what you built. It’s to find out which design deserves to exist.

How to grow an agent team

1. Start with one agent and one measurable outcome. Give it the tools it needs and clear limits on its authority. Watch where it fails, hesitates, repeats work, or needs a person.
2. Sort the failures. Some are about information access. Others are about reasoning, state, tool reliability, permissions, or workflow design. Only some can be fixed by another agent.
3. Add a second agent only when the evidence supports it. Give it a distinct job and a structured handoff, and keep the original success criteria so you can compare against the baseline.
4. Add a coordinator only when work truly needs delegating across independent workers, not because every team supposedly needs a manager.
5. Keep everything visible. Decisions, evidence, state changes, and failures matter more as automation grows, not less.

This looks less ambitious than launching a fully autonomous team on day one. In practice it gets you further, because each step gives you a solid base for the next.

Single vs. multi-agent is the wrong question

Some workflows will gain a lot from specialized agent teams. Others will stay simpler and more reliable with one well-designed agent. The real difference is between systems built around proven needs and systems built around what the technology makes possible.

We put intelligence where it creates measurable value, add coordination where separate responsibilities require it, and scale human oversight to the stakes of each action. The best architecture is the simplest one that reliably gets the result, and that can show why any extra complexity is worth what it costs.

Start with one. Learn its limits. Let the next agent earn its place.

Planning your first production agent? See how we build Deployable AI for teams.