TL;DR

If you can see all the steps clearly if you were to do the task yourself, and you’d always solve it the same way, you should be building your agent with the same principles. Ten Trillion Triangles TPipe gives you the smallest primitives to express that. The cheapest agent is the one that mirrors the engineer who knows what they are doing.

The rule that decides everything

Ten Trillion Triangles TPipe ships a stack of orchestration primitives. At the bottom: Pipe, the unit of encapsulation for one LLM call. Connector, conditional branching that maps keys to Pipelines. Splitter, fan-out across a routing key. Pipeline, a sequence of Pipes sharing a context. Above Pipeline: Manifold, Junction, PumpStation, DistributionGrid. Containers that compose Pipelines into agent hierarchies with manager pipelines, worker rosters, harness search, and station-agent background loops.

The temptation is to reach for the top of the stack because the container looks like it solves the problem in one move. The rule says the opposite. The cheapest agent on Ten Trillion Triangles TPipe is the one that solves the problem using the smallest primitive that carries it.

The statement is about cost, control, and the engineering depth you keep when the routing decisions stay with the engineer and you keep paying only for what you wrote.

Three branches, escalating only when the lower branch cannot carry

The decision tree an engineer walks when designing an agent on Ten Trillion Triangles TPipe runs three branches. Each step up trades a known quantity for an unknown one. The trade is only worth it when the lower branch genuinely cannot carry the problem.

Decision tree for picking the smallest primitive on Ten Trillion Triangles TPipe. Three branches escalate only when the lower branch cannot carry the problem. Pipeline plus low-level primitives is the first branch, with the lowest token cost, highest control, and highest governance. Manifold is the second branch for problems arriving in unknown states of completion. PumpStation and Junction class is the third branch for many problems at once under a rough scope of possible solutions. A diagnostic on token cost and turn count feeds back across all three.

Branch 1 — Pipeline plus low-level primitives. The engineer knows the problem. The engineer knows the exact steps. The engineer knows the shape of the output. The agent is a Pipeline composed of Pipes, with Connectors for conditional branching and Splitters for fan-out where the routing decision is deterministic. Token cost is the lowest because there is no coordination overhead above the LLM call itself. Control is the highest because every token that hits the model is a token the engineer wrote or wired. Governance is the highest because the trace is the engineer’s trace — every Pipe ran, in the order the engineer specified, with the context the engineer composed.

The catch: the engineer has to know the problem in advance. If the engineer is wrong about the shape of the solution, the Pipeline fights them on every turn. This branch is for problems the engineer can solve themselves, the same way, every time.

Branch 2 — Manifold. The engineer knows the kind of problem, but the problem arrives in various states of completion. An email might be a complaint, a refund demand, a feature request, or a question. The engineer cannot tell which until the input has been read. The Manifold pairs a manager Pipeline that classifies on arrival with a roster of worker Pipelines that handle each class. The manager pays one LLM call per turn to decide routing. The worker runs the deterministic sequence for its class. Token cost is higher than a Pipeline because the manager burn is per turn. Control is lower because the manager is making LLM-driven routing decisions the engineer can prompt-patch but cannot directly override. Governance is still good because Manifold traces carry the manager decision and the worker execution path, and the engineer can audit both.

The catch: the problem space has to be bounded. There are N possible shapes and the engineer can name them. If the engineer cannot enumerate the shapes, the worker roster is incomplete and the manager will route to the wrong worker with no recovery path.

Branch 3 — PumpStation or Junction class. Many problems arrive at once. The engineer has a rough scope of possible solutions but does not want to engineer a worker for each case individually. The PumpStation itself is the mechanism that finds or builds the right harness agent per problem. Station agents run in the background — judge, dispatch, intervention, summary, lorebook, goal, health — paying coordination cost per turn whether or not they influence the current output. Harness agents are dispatched, run, and their output flows back through the working content. Token cost is the highest. Direct control is the lowest. The trace tree is now nested P2P conversations.

The catch: the harness search has to find the right agent. When it fails, the failure is silent. The harness produced output that does not address the actual problem, and you are reading the trace to figure out which station agent should have caught it.

The diagnostic for reaching back down

Engineers reach up the tree too early. The diagnostic for catching it is empirical and runs two axes.

Token cost ratio. The engineer knows the input. The engineer knows the desired output. The question is what the task costs in tokens versus what it should cost for the abstraction chosen. A “summarize this document” task that burns eight thousand tokens when it should burn twelve hundred is in the wrong band. The band is set by the abstraction: Pipeline-class tasks run at the lowest token cost. Manifold-class tasks pay one manager call per turn on top of the worker cost. PumpStation-class tasks pay station-agent overhead per turn on top of the harness dispatch. If the actual numbers land in a higher band than the abstraction chosen, the abstraction is wrong.

Turn count ratio. Some problems take one turn. Some take five. Some take twenty. A PumpStation doing a Pipeline job might solve the problem in twenty turns where a Pipeline would have done it in two. The abstraction is buying the engineer turns the problem did not require. Count the turns. If the count is in the wrong band, the abstraction is buying the engineer something the engineer did not need.

The trace signature follows. A manager Pipeline making a decision a switch statement could have made. A harness dispatching to a worker the engineer could have wired directly. Station-agent activity that produced no observable effect on the output. The trace is the engineering-depth proof that the right abstraction was chosen.

The scar of staying at Branch 1 too long

The opposite failure mode is also real. The engineer chose the smallest primitive, and the problem outgrew the engineer’s mental model. The prompt grew. The Pipeline’s LLM started behaving like a manager anyway, but without the trace signatures or the governance primitives the manager class ships. The engineer built a worse Manifold by hand, and it costs more than the Manifold would have cost because the engineering time and the cognitive load keep compounding.

The scar is engineering time and cognitive overload. Once the engineer can no longer visualize the routing in their head, the smallest primitive has failed them. At that point the cost of staying at Branch 1 is higher than the cost of reaching for Branch 2. The win was always the bigger abstraction once the system outgrew the engineer’s mental model. The loss was staying at the smaller primitive past the point where the cognitive load exceeded the cost of the bigger primitive.

The diagnostic is harder than the cost ratio because the engineer is measuring their own ability to reason about the system, not a number on a dashboard. But the rule is clean: when the engineer can no longer hold the routing in their head, the engineer has already paid more than the bigger abstraction would have cost. Reach for it now. The bigger abstraction is audited. The hand-rolled manager is not.

Why the substrate gives you the smallest primitives

The substrate gives you the smallest primitives because the cheapest agent is the one that mirrors a person who knows what they are doing. A person sending an email reaches for an email primitive. A person summarizing a document reaches for a summarize primitive. The person reaches for the smallest primitive that carries the task, and only escalates when the task itself demands it.

Ten Trillion Triangles TPipe is a substrate that asks the engineer what they would do. The primitives are there to let the engineer express the answer. The bigger abstractions are there for the cases where the engineer’s own answer is “I do not know yet, and the problem will not tell me in advance.”

The cheapest agent on Ten Trillion Triangles TPipe is the one that solves the problem the way the engineer would solve it, using the smallest primitive that carries the solution, escalating only when the engineer’s own answer would escalate. The substrate makes the discipline cheap to follow.

Frequently Asked Questions

What is the smallest agent scope in Ten Trillion Triangles TPipe?
The smallest agent scope is a Pipeline composed of low-level primitives: Connector for conditional branching, Splitter for fan-out, and Pipe instances for individual LLM transformations. The Pipeline runs a known sequence of known steps with no manager overhead, no coordination state, and no abstraction above the LLM call itself. Token cost is lowest. Control is highest. Trace governance is complete.
When should an engineer reach for the Manifold instead of a Pipeline?
Reach for the Manifold when the problem can arrive in various states of completion and the engineer cannot anticipate how complete it is. The Manifold pairs a manager pipeline that classifies each input on arrival with a roster of worker pipelines that handle each class. The engineer trades direct control over routing for adaptive dispatch.
When should an engineer reach for the PumpStation or Junction class?
Reach for the PumpStation or Junction class when many problems arrive at once under a rough scope of possible solutions and the engineer does not want to engineer a worker for each case individually. The PumpStation searches for or builds the right harness agent per problem. Token cost is the highest. Direct control is the lowest. The abstraction earns its cost by trading known coverage for unknown problems.
How does an engineer know they have reached too high in the abstraction?
Run the cost diagnostic. Compare the actual token spend and turn count for a task against the expected band for the abstraction the engineer chose. If a Pipeline-class task is spending tokens or turns in the Manifold or PumpStation band, the abstraction is wrong. The trace signature follows: a manager making decisions a switch statement could have made, or a harness dispatching to a worker that the engineer could have wired directly.
What is the scar of staying at the smallest scope when the problem needs more?
The scar is engineering time and cognitive overload. Once the engineer can no longer visualize the routing in their head, the smallest primitive has failed them. At that point the cost of staying small is higher than the cost of reaching for the next abstraction. The prompt grows. The Pipeline's LLM starts behaving like a manager anyway, but without the trace signatures or governance primitives. The engineer has built a worse Manifold by hand.
Why does a bigger container cost more tokens per turn?
Containers carry overhead per turn by design. A Manifold pays for a manager LLM call every turn. A PumpStation pays for the station agents running in the background — judge, dispatch, intervention, summary, lorebook, goal, health — plus the harness agent dispatched for the current problem, plus nested harness-of-harness if applicable. The container is doing what it was designed to do. The cost surfaces when the container is solving a problem the engineer did not have.
What is the single-sentence rule for choosing the right scope?
If you can see all the steps clearly if you were to do the task yourself, and you'd always solve it the same way, you should be building your agent with the same principles. The rule implicitly defines when to escalate: when you cannot see the steps clearly, or you would solve it differently each time, that is when the bigger abstraction earns its cost.