What a 10-Minute Agent Build Reveals About Real Architecture

What working with LangGraph, Deep Agents, and TrueForge revealed about abstraction, control, and how agents actually behave.

While building DEVIN, a large share of the effort went into work that never shows up when someone simply uses an AI agent.

Wiring up Deep Agents.

Configuring Daytona as the sandbox environment.

Using Ingest to handle streaming and background execution.

Getting all of these pieces to cooperate.

Progress was slow.

But somewhere inside that grind, a clearer picture emerged of what actually makes up an agent system.

Not just the model itself.

Everything surrounding it.

The runtime.

The tools.

The sandbox.

The orchestration layer.

The way agents talk to each other and hand off work.

Then a hackathon came along, and with it, TrueForge.

Almost immediately, it became obvious how much of the infrastructure that had been painstakingly assembled by hand could instead be handed off to a platform.

Putting together a working agent took no more than about ten minutes: hooking up the relevant MCPs, dropping in the necessary tools, drafting a SKILL.md file describing the behavior, and then simply executing it.

After all the time spent building infrastructure from scratch, this felt almost too easy.

And honestly, it was impressive.

That is exactly what good abstraction should feel like.

But the trade-off hidden inside that ease wasn't obvious yet.

The 10-minute agent

The first reaction was pure admiration for how effortless the process was.

TrueForge took care of the surrounding infrastructure, leaving the main job of describing what the agent should actually do to the skill definition.

That is a genuinely strong abstraction.

The MCPs being added were visible.

The tools were visible.

The SKILL.md file was visible.

Everything felt legible and easy to reason about.

So the habit of reaching for it stuck.

It was only with continued use that a subtler issue surfaced, one that hadn't registered during the hackathon itself.

The concern wasn't what could be inspected.

The concern was where the actual architecture lived.

A skill by itself isn't an architecture

The root agent reads the skill file and uses it to decide how to apply the capabilities it has been given, including how and when to spin up sub-agents.

That means a single SKILL.md can end up quietly defining a large portion of the agent's behavioral structure.

Imagine wanting to build something like this:

                    Root Agent
                   /          \
                  /            \
            Researcher        Coder
                /                \
               /                  \
          Searcher              Tester

Simply telling the root agent something like: "here are your tools, spawn whatever sub-agents you need and work it out," isn't the same as designing the system.

What actually matters is defining the architecture directly:

• which agents exist
• what each one is responsible for
• which tools go to which agent
• what context each agent receives
• when delegation should happen
• what the recovery path looks like after a failure

That's the distinction that started to stand out.

Working with the Deep Agents approach, the architecture is something you deliberately construct.

Working with TrueForge, the infrastructure side is far simpler, but the behavioral architecture ends up depending on whether the root agent interprets the skill the way you intended.

That dependency ties the whole system's behavior much more tightly to the underlying model.

A more capable model might read the skill exactly the way it was meant to be read.

A weaker model might take a completely different route through the same instructions.

Same skill file.

Same tools.

Different resulting behavior.

The architecture on paper hasn't changed.

Only the model's interpretation of that architecture has.

That gap is what made this approach harder to fully trust.

Working on AEGIS reinforced this concern

While building AEGIS, the team ran into a straightforward but revealing problem.

The agent was supposed to investigate cases of Node.js event-loop starvation.

It needed to inspect code, reproduce the issue, measure runtime behavior, diagnose the root cause, propose a fix, and confirm that the fix actually worked.

Early on, the verification stage was mostly just a prompt telling the model what to do, along the lines of:

Execute the experiment, compare the resulting metrics, and judge whether the fix actually solved the problem.

Yet letting an LLM be the one to decide whether its own patch succeeded doesn't really count as verification.

So the deterministic portion of that logic was moved into code instead of prompt text.

The model does the reasoning.

The system performs the measurement.

The verifier makes the call.

That experience produced a principle that now applies broadly to agent design:

If something cannot be observed, it cannot be properly tested. If it cannot be tested, it cannot be evaluated. And if it cannot be evaluated, it cannot be reliably improved.

This is precisely why architecture matters.

Not because a diagram with more boxes and arrows is inherently superior.

Because you need a clear account of what produced the behavior you are trying to improve.

"It works" versus "I understand why it works"

Two different agents can both technically succeed.

Both can complete the assigned task.

Both can look great in a live demonstration.

The real test comes when something goes wrong.

With one kind of agent, it's possible to trace the exact path of execution:

Root Agent
    ↓
Researcher
    ↓
Search Tool
    ↓
Result
    ↓
Root Agent
    ↓
Coder
    ↓
Sandbox

Each decision point can be examined and questioned:

Why did this particular step happen?

With another kind of agent, there's only a skill describing the intended outcome, while the model figures out the path on its own.

When that works, it feels remarkably simple.

When it fails, the debugging question becomes much harder to answer:

Was the failure caused by the model, the instruction, the delegation logic, the context provided, or the architecture the model improvised on its own?

That second scenario is a far more difficult problem to untangle.

And that's what TrueForge taught

Before spending time with the platform, the natural assumption is that the hard part of building agents lives entirely in the infrastructure layer.

Working with it changes that view. Infrastructure turns out to be only half the challenge.

Infrastructure is something you can abstract away.

Behavior resists abstraction.

A platform can hand over a sandbox.

It can hand over MCP.

It can hand over streaming.

It can hand over the whole runtime.

Yet if you're building an agent whose actions actually matter, you still have to answer some questions yourself:

What component is making which decisions?

What is permitted to do what?

Where exactly does delegation occur?

What visibility do you have into the process?

What can you actually measure or evaluate?

What levers exist for fixing things when they break?

These are the pieces no one should hand off without thinking twice.

How long does it take to understand why it failed?

Assembling an agent in ten minutes is a genuinely impressive feat.

But a more useful question starts to matter more than that speed:

How long does it take to understand why it failed?

Production environments don't reward a successful first demo.

What they punish you for is the tenth failure.

The tool that returns something unexpected.

The weaker underlying model.

The agent that hands off work when it shouldn't.

The agent that fails to hand off work when it should.

The agent that announces "Done."

while nothing has actually been accomplished.

That's precisely where architecture earns its keep.

What was actually learned

Reflecting on the DEVIN project, the real takeaway wasn't mastering Deep Agents, Daytona, or Ingest as standalone tools.

It was grasping how the components of an agent system connect to one another.

TrueForge then demonstrated how fast those same components can be abstracted out of view.

And using it revealed the flip side of that convenience:

Infrastructure can vanish from a workflow without behavior vanishing along with it.

Someone still needs to govern that behavior.

Someone still needs to watch it in action.

Someone still needs to assess whether it's working.

And someone still needs to decide what gets changed once it fails.

That responsibility is one worth keeping close, not outsourcing.

Where agent architecture is heading

This experience also reshapes how the trajectory of agentic systems can be understood more broadly.

The field has progressed through stages:

models → tools → MCP → agents → deep agents

and at each stage, the surrounding infrastructure keeps getting simpler to obtain.

The layer that matters most going forward, in this view, is the harness surrounding the model.

Not merely the model's raw capability, but the system supplying it with:

context, tools, execution, permissions, orchestration, memory, observability, evaluation, and control.

As models keep improving, raw model quality alone will stop being the deciding factor.

The engineering question worth asking will increasingly be:

What environment has been constructed around the model, and how much command exists over how it behaves?

That's arguably the central lesson from building DEVIN and later assembling an agent in ten minutes.

The simpler it becomes to build an agent, the more critical it becomes to understand everything surrounding it.