LAB.05 / Agentic Systems

One agent is easy. A system is not.

Anyone can build an agent that works in a demo. The problem starts when there are fifteen of them, the task changes every time and nobody is watching the screen.

01 / Philosophy

What this laboratory studies, and why.

Object

Multi-agent systems almost always fail for the same reason: they are built with a fixed topology. Someone decides the task is solved by these five agents in this order, and that order is applied equally to a trivial request and to one that decides a company's positioning.

The consequence is contradictory. For simple work the system is absurdly slow and expensive. For complex work it falls short, running in parallel things that depended on each other and producing an internally incoherent result nobody notices until a human reads it.

Topology should be a decision, not a constant. That is the central line of this laboratory, and the one that carries into every other lab: the orchestration built here is what runs the systems in the other four.

Why

Almost everything published about agentic systems is a demonstration: one chosen task, run once, reported by whoever built it. Nothing can be decided from that, because what determines whether a design holds is how it behaves when the task changes and nobody is watching.

Here the unit of work is the controlled comparison: same task, same base model, one variable changed, with the numbers from every run on the table — including the one that came out worst. It is slower than publishing a demo, and it is what allows an architectural decision to rest on evidence instead of intuition.

How it works
Principle 01

Where it pays

Agentic systems pay off on knowledge processes that repeat with variation: producing technical documentation, qualifying and answering enquiries, reviewing files against criteria. Work whose substance is read, decide, write.

Principle 02

Where it does not

Not on purely transactional processes, where an ordinary integration is cheaper and more reliable. Not at volumes so low that maintaining the system costs more than doing the work by hand.

Principle 03

The cost argument

The fullest mode can cost an order of magnitude more than the simple one for the same request. A system that does not choose its mode is paying that premium on every trivial request — which is most of them.

02 / Projects

Systems and evidence.

  1. P-01
    In production

    Adaptive orchestration

    An orchestrator scores each request on six measurable dimensions — time pressure, who consumes the output, causal dependency between parts, strategic risk, completeness of the brief, and need for external research — and derives the execution mode from that score. The same request phrased more urgently is resolved by a different route, and the system says why.

    Low score

    Sequential

    One agent end to end. No coordination cost. Correct for a bounded, low-risk request — and the mode most people avoid because it looks unsophisticated.

    Mid score

    Parallel team

    Specialised agents work simultaneously on independent parts. Multiplies depth when the parts are genuinely independent; produces incoherence when they are not.

    High score

    Pipeline

    Phased execution over a shared workspace where each agent leaves findings the next ones read. Allows real causal dependency, at the cost of time.

    Two hard rules override the score: maximum urgency always forces sequential, and the combination of high causal dependency with high risk always forces the pipeline. Every decision is logged with its per-dimension score, so the quality of the criterion can be audited afterwards against the outcome.

  2. P-02
    Completed

    Controlled comparison of execution modes

    The same task run three times — same brief, same base model — changing only the topology. The task was producing five strategic analysis documents.

    SequentialParallelPipeline
    Execution timeimmediate~3 min~20 min
    Words produced2,30611,44314,577
    Critical alerts raised63239
    Findings absent from the brief046
    Client errors corrected012
    Knowledge shared between agents——1,774 words
    Fig. 1 — Going from parallel to pipeline adds only 27% more text for seven times the time. On volume alone the pipeline never pays.

    But volume is not what changes. In the parallel run an agent accepted a competitor's business category because nobody told it otherwise; in the pipeline that same analysis checked the real website and found the competitor belonged to a different category — an error that would have contaminated the entire positioning built on top of it.

    The detail that settles the design: the two documents in the first phase — the ones with no agent ahead of them — came out practically identical in both modes. The pipeline's gain lives entirely in causal dependency, which is exactly the dimension the orchestrator measures before choosing.

  3. P-03
    In production

    Architecture patterns that survive

    • Separate agent, capability and procedure; merging them into one long prompt makes failure impossible to locate
    • The written procedure outranks the agent's improvisation — that is what makes runs reproducible
    • Shared domain context, separate per-agent memory
    • A shared workspace instead of messages between agents: slower to design, far more robust, and the state stays inspectable
    • Verification as a phase with a binary outcome, not as an optional step in a prompt
    • Missing context halts execution: a generative system without context does not fail loudly, it fails by producing something plausible and generic