An analysis of seven axes: nine frameworks, thirteen planning schemes, thirty-five findings on worker selection, forty-seven on fuses and proofs, seventeen commercial products, a check of our numbers, and a red team. Plus what follows from this for our 'goal in words' door.
A swarm in someone else's hands is built from three layers, and almost the entire difference between products comes down to who makes the decision at each one: who breaks the goal down into units of work, who chooses the executor for a unit, and what stops the work when it gets more expensive. The analysis of nine frameworks shows that breaking down the goal is handed to the model in most cases, while hard limits, if they exist at all, are almost always set by the developer in advance.
Three conclusions concern us directly. First: none of the nine frameworks offers a ready-made step of 'a human writes the goal, the system proposes a draft of the work's form, the human confirms.' That spot is open. Second: our mandatory money ceiling, which stops a branch before the next paid call, appears in others as a first-class citizen in only one toolkit, and more often looks like a spending counter that stops nothing. Third: the red team brings one unpleasant amendment to our wording, and it must be accepted: our proof is a proof of integrity, not of correctness, and it must be named precisely.
The most frequent point of failure in other people's swarms is not the model and not the connection between agents, but the way the task is posed. The largest class of failures in trace analysis, almost 42 percent, falls on the specification rather than on execution, and a planner at the level of the best models solves an everyday trip task correctly in zero point six tenths of a percent of cases. From this follows a simple conclusion: when a person writes the goal in words, the entire burden of correctness falls on the confirmation step, and if it is framed as "press and go," correctness remains nobody's responsibility.
The variety of frameworks is confusing only on the surface. Beneath it lies the same scheme of three decisions, and in each of them the answer can be given either by the developer or by the model.
The first decision: who breaks the goal down into units. At Anthropic it is the main agent, at Claude Agent SDK the main agent through a tool, at AutoGen an orchestrator with a task ledger, at AWS the model splits the request into steps. On the other side are LangGraph, where nodes and connections are written in advance, CrewAI with tasks and flows, and Google's templated schemes, where the sequence, the parallel branch, and the loop are set by the developer.
The second decision: who chooses the executor for a unit. Here, in every single case without exception, the model decides, and the only difference lies in what it is shown: the full list of capabilities, a short list obtained through search, or a single pre-selected executor.
The third decision: what stops the work. This is the weakest part of other people's practice, and the analysis of fuses confirms it almost verbatim: step counters exist, while monetary limits as hard constraints are almost nonexistent.
Below is consolidated what matters for the solution: who breaks down the goal, whether the end person can write it out in words, and which limits are hard-set in the framework itself.
| Framework | Who breaks down the goal | Goal in words from the person | Hard limit |
|---|---|---|---|
| Anthropic, a research swarm | Main agent | Yes, fully | There is no limit in the documentation; the mentioned failure is the spawning of fifty sub-agents without control |
| Claude Agent SDK, sub-agents | Main agent as a tool | Partially: the string is accepted, the composition is set | Nesting depth is three levels by default; a sub-agent cannot spawn a sub-agent |
| OpenAI Agents SDK | The model chooses a branch from developer-written handoffs | Partially | Number of steps per run; exceeding it causes a failure; it can be disabled explicitly |
| LangGraph | Developer: nodes and connections in advance | No | A graph step counter; exceeding it causes a failure |
| CrewAI | Developer: tasks and flows | Partially, through the studio | Limit on requests per minute; there are automatic checkpoints |
| AutoGen and Magentic-One | Orchestrator with a task ledger | Yes, fully | There is no numerical limit in the guide: safety is relegated to instructions, not to code |
| Google ADK | Developer: sequence, parallel, and loop patterns | Partially | The number of loop iterations, for example ten |
| AWS Bedrock Agents | The model breaks the request into steps | Yes, fully | There is no numerical limit; everything is in the platform's hands |
| Semantic Kernel | The developer or the model, in different modules | Partially | No, the module is marked as experienced |
This table should be read with one caveat: the absence of a number in the documentation does not equal the absence of a limit in the code. But for the buyer these are one and the same, because the only thing he can verify is the document.
We have landed in a rare position: our limit is named as a number, sits in the code, is applied before every paid call, and is recorded in the plan line together with whoever declared that number. Out of nine frameworks, no one does this.
The analysis was separately interested in monetary ceilings, and the result is worth reading carefully, because it explains why our ceiling looks stronger than the market.
The limits that actually stop things look like this. In one toolkit, the session budget is set by two numbers: a limit on the number of calls and a monetary limit per session, and the check happens before the call, not after. In another product, the agent is given a hard budget for a period, and once it is exhausted, the next request to the model is refused with an error code. In a third, exceeding it returns a budget rejection, and if the gateway cannot read the budget, an unavailability rejection is returned, that is, the system shuts down rather than running blind.
And now what looks like a limit but is not one. The largest model provider states outright in its documentation: spend notifications do not limit spending. Individual toolkits provide a step counter or an iteration counter, which does indeed stop the loop but says nothing about money. And most of the frameworks examined have no monetary limit in their documentation at all.
The red team brought a case where a multi-day pipeline looped for 264 hours and issued a bill of about 47 thousand dollars. This is not about the model, but about the point where the constraint stands: the limit inside the loop sees the moves, while the money goes away with each move. The public analysis of this case comes from secondary sources, therefore in our text it is marked as unverified, but the conclusion does not change because of this.
A separate question of the analysis: does any framework give a step where the end human writes the goal in words, and the system offers a draft of the work for confirmation. Answer: no such step exists in any of the nine as a ready-made capability.
In three, the goal in words is accepted in full, but then the system decides on its own and executes on its own: the human does not confirm the analysis. In five, the line is accepted, but the composition of executors is fixed in advance, that is, the goal in words merely chooses from a ready-made set. In one, it is absent altogether. And in only one toolset is the money ceiling described as a first-class constraint, that is, as something that stops.
The goal in words falls inside the black box: the analysis, the choice of executors, and the execution go in a single loop. The human sees the result or a question when the system has already done something.
The draft is visible before the money: the form of the work, the list of units, the ceiling, and the reason. The model proposes, the planner checks with the same edges, the human confirms, and only then does the work begin.
Our confirmation step does not copy the market, because the market does not build it. But precisely because of this it will have to be explained: the human must be convinced that an extra step before launch is not slowness, but the only barrier between the correctly sounding and the correct plan.
The literature on how a goal turns into a plan is homogeneous in idea and very concrete in numbers. Almost every scheme divides the work into a plan phase and an execution phase, and they differ in who checks the plan and when exactly the money is spent.
| Scheme | What it does | Measurement | Year |
|---|---|---|---|
| Plan and execute | A separate plan step before the work steps | Consistently outperforms step-by-step reasoning on ten datasets | 2023 |
| Reasoning without observation | The plan is composed in full, before the first tool call | Reduction in token consumption by 64% with an increase in accuracy 4,4% versus the interleaved scheme | 2023 |
| Reflection on the error | Verbal feedback without training the weights | First-attempt pass rate up to 91,0% versus 80.1% for the previous best | 2023 |
| Tree of thoughts | Branching of options with evaluation of the branches | The game of "twenty-four": 74% versus 4% for simple reasoning | 2023 |
| Tool Compiler | Parallel calls are assembled into a task graph | Up to 3,7x faster in latency and up to 6,7x cheaper with an accuracy gain of about 9% | 2023 |
| Task graph with model selection | A plan, then selecting an executor for each step | Going through planning 91,22, model selection 93,89 | 2023 |
| Skill library | A growing library of mastered actions | 3,3x more unique items in the Minecraft environment than the previous best | 2023 |
| Decomposition when necessary | Splits the task only when it cannot be solved as a whole | Up to +28,3 points in one environment and +27 in another | 2024 |
| Modular plan with a verifier | The plan is checked by an external tool, not by the model | Positional work: the model can neither plan nor verify itself on its own | 2024 |
| A set of tasks for analysis | Measures the correctness of the analysis and of the connections separately from execution | A metric for the quality of connections between steps was introduced | 2023 |
| A set of tasks for planning | Classical block-stacking (block rearrangement) problems | The best model of that time 34,3%, the previous one 6,8% | 2022 |
| Reasonable parallelization | Checks when parallelism hurts | Parallelize every level hurts: alignment and repeated research cost more | 2025 |
| The verification limit | An external signal decides when to stop | Models do not correct themselves without external verification | 2024 |
Of the thirteen schemes, nine appeared before 2024, and this matters more than it seems: the framework market is young, while the idea of “first the plan, then execution” is not new and has been repeatedly measured. We did not invent it in our plan line; we joined it.
The gain from the plan is achieved not by the power of the executor, but by separating planning from execution. Where the plan is drawn up in full before the first paid call, spending drops severalfold while accuracy grows. This is exactly our design: the plan line is written before the first call.
All schemes that have numbers are divided into two times. Plan time: the goal is decomposed, the units are named, order and connections are defined. Execution time: money is spent, tools are called, results appear. The scheme that cuts spending by 64% does so precisely because the entire plan is assembled before the first call to a tool.
From this it follows where human intervention is possible at all. Up to this boundary he can change the shape of the work and the list of units almost for free. After it, all he can do is stop, and stopping costs what has already been spent. Therefore in other people's practice approval most often stands precisely at the boundary, and ours too.
Here is the measurement most useful for us: parallelism does not give a linear gain, and its real width in other people's hands is smaller than it seems. One of the schemes honestly explains why there is no speedup by as many times as there are executors: the costs of the scheduler are added, the costs of reduction, and the slow link that delays the entire branch. The measured average width of one of the agents is about 1,7, that is, it almost always works alone even when it can split the work.
Another 2025 work shows something counterintuitive: parallelizing every level is harmfulbecause the fee for alignment and re-exploration of what has already been traversed grows. This is exactly the justification we need for a strict small ceiling: not "we don't know how", but "a wide fan is more expensive than it is useful".
The ceiling of four does not restrain the model's imagination; it holds the branch in the zone where the fan is still cheaper than solitary work. Someone else's measurement of the average width and someone else's finding about the harm of full parallelism make this number not our taste, but a consequence of measurements.
The second layer is the choice of executor. Here the analysis brought the largest number of measurements, and all of them say one thing: the quality of choice falls as the list of candidates grows, and this is cured not by a smarter model, but by a shorter list.
On a deployed industrial assistant with a list of 110 agents and 584 tools the selection of the worker degrades, and the analysis shows what the loss consists of: part of the failures is the inability to find the needed candidate at all, part is confusion already under ideal search. A short list built on vectors returns 10-11 points of quality and helps at every scale. A hierarchical one with two stages, where the model first chooses a group and then within it, turned out the worst of all: about 47,9% quality with the full list, that is, two-stage selection does not save, but harms.
A separate finding that would cost us dearly in deployment: models have a tendency to choose candidates standing higher in the list. Shuffling the order killed most of the gain from the short list. This means that the order in which we show forms and units affects the result more than we thought.
| Measurement | Number | What follows from it |
|---|---|---|
| Short list on vectors versus the full enumeration | 13,62% → 43,13% | Candidate selection matters more than model power |
| Short-list search at the scale of 110 agents | +10-11 points | The gain holds across the whole scale, not just at small scale |
| Two-stage selection within groups | 47,9% | A hierarchy with the full list is worse than a flat short list |
| Selecting an application out of a hundred with a strong model | 63,3% | Even strong models stumble on a large catalog |
| The cost of tool descriptions in context | about 150,000 tokens for 500 descriptions | The full list of roads even before the first call |
The tendency to choose whatever stands higher in the list is not a minor interface detail but a change in the result. For us this is a direct requirement: the list of forms must be ordered by a meaningful rule, and nothing extraneous may be mixed into it, because the system will read "just so it's there" as "this is important".
From the practice of analysis a corridor takes shape, one into which our children's ceiling falls. The first five options are chosen reliably, up to ten the work is still possible, starting from two dozen noticeable degradation begins and search becomes necessary, and at hundreds of options the choice turns into a lottery.
Four units, four forms in the list, seven models in the catalog. We operate where the choice is still precise, not where degradation begins. If one day you want to raise the ceiling, you will have to show what this loss of precision was paid with.
The breakdown separately noted the mechanism of each decision, because whether anything can be verified and explained at all depends on it. Below is brought together who decides and with what, when it comes to choosing a worker or a form.
| Mechanism | Where it occurs | Verifiability |
|---|---|---|
| Rules | Threshold decisions, hard ceilings | Full: the rule is visible and repeatable |
| Vector search over a shortlist | Intent router, candidate selection | Good: the list can be replayed and compared |
| Model call over a shortlist | The primary method across all nine frameworks | Partial: the decision is visible, the reason is not |
| Two-stage selection by the model | Hierarchical router | Worse than flat: 47.9% with the full list |
| Human | Confirmation of form and units is on our side | Full: this is exactly our mainstay |
For us this means that the decision about the form of work must not be entirely model-based, otherwise there will be nothing to verify it with. And it is not entirely model-based: the model proposes, the rules check, the human confirms, and only this chain provides verifiability.
The breakdown of fuses is valuable because it separates the constraint from the meter. Below is what stops, and what only reports.
| Someone else's solution | What it does | Class |
|---|---|---|
| Session budget of two numbers | Limit on the number of calls and a monetary limit, check before the call | Stops |
| Agent budget per period | When exhausted, the next request is rejected with a code | Stops |
| Spending ceiling in the gateway | Rejection due to budget, and if the budget cannot be read, rejection due to unavailability | Stops, closed |
| Policy on the cost expression | A condition of the form "cost greater than one and environment is combat" blocks the action | Stops |
| A wrapper over the model client | Checks spend before each call and refuses after exhaustion | Stops |
| Spend notifications | They write a warning, spending continues | Only reports |
| Counter of steps and iterations | Stops the loop, does not introduce a monetary limit | Stops the loop, not money |
Our construction belongs to the first part of the table: the check is placed before the call, upon exhaustion the child refuses before spending, and if the check itself fails, the branch also stops, that is, closed.
If the gateway cannot read the budget, it returns a rejection due to unavailability rather than working blind. This is the same rule as ours: a broken check stops the work. Our case is not an invention but a coincidence with the most cautious practice.
Here the analysis yielded unpleasant details, and they are worth knowing, because they explain why the buyer treats 'confirm the plan' without trust.
In one toolkit, tool approval is turned off by default for all tools, and the two most powerful types of tools cannot be covered by approval at all. In another, the confirmation flag stands only before issuing the final answer and, according to the user's report, does not prevent executing a tool before confirmation: the agent does the work and then waits for the human. In the third, confirmation is enabled only when the developer explicitly switches the mode.
The general threat document names excessive agent autonomy as a separate threat and recommends limiting actions by consequences, not by steps. The red team adds to this two cases where confirmation was formal and the agent did something other than what it was asked.
Plan confirmation covers the intent, not every action inside the branch. This means the strength of our control must be in the same place as that of the most cautious: before a paid call, which is exactly where we stand. And in the conversation with the buyer, the boundary must be named honestly: before confirmation we protect the money, after confirmation we protect only the account and the trail, and actions inside the branch are protected by the tool's rules, not by a human.
The outside market of agent observability is rich in tracing tools: unified conventions for how to record model calls, open formats, viewing platforms. But the analysis emphasizes a boundary that must be kept in mind: the trace shows what was happening and does not prove that what happened is exactly what was recorded, because the recording is made by the ward itself.
Hence our answer. Our fingerprint is computed over five fields of each child and is recalculated from the table upon reading, that is, from a record that lies outside the executor itself. This makes it a proof of integrity: the branch cannot be rewritten unnoticed. But it does not prove that the branch did something useful: these are different statements, and they must not be confused.
Our proof answers the question 'the branch is the same as it was', not the question 'the branch was right'. The second is proven only by checking the result, and that is separate work that we do not yet have.
From the analysis, the section on proofsThe commercial part of the analysis looked not at frameworks but at products where a person formulates the goal and the work begins. All seventeen accept the goal in words somewhere, and all set a limit somewhere, but these limits are almost always measured not in money but in their own internal unit: an action, a credit, a run.
| Product | How the goal is set | Who chooses the executors and goals | Limit |
|---|---|---|---|
| Agent builder from the largest model provider | A flowchart of nodes plus a verbal goal | Flowchart developer, model inside the node | Flowchart versions, checks and guardrails as separate nodes |
| Working agents in the same product | In words, without a flowchart | Model | App permissions separate reading and action; can operate without a human |
| Agents in the automation builder | In words | Model within the bounds of connected apps | Counted in actions: four hundred free per month, but no more than ten per run |
| Lindy | In words | Model | Credits, consumed only while it runs; when exhausted, the pool stops |
| Relevance AI | In words | Model | Dual counter: actions and model credits, with credits passed through at cost price |
| Gumloop | In words and blocks | Model | Credits; pricing was unified on December fifteenth, 2025 |
| n8n | Schema and verbal nodes | Developer | Counted in runs: five concurrent on the top tier, a run-time limit |
| Agentforce | Topics and verbal instructions | Product planner | The full sequence is planned before execution, a human connects only on escalation |
| Copilot Studio | Verbal configuration of topics and actions | Topic developer | Credits: in effect one cent per credit, a two-hundred-dollar package for twenty-five thousand credits |
| Google Opal | Verbally and in blocks | Model | An experienced product, no spending limits have been announced |
| Sierra | Verbally, for a support task | Product | Payment per resolved case; there is no spending cap for the buyer in the documentation |
| Decagon | Verbally, for a support task | Product | No public pricing; payment per conversation or per resolution |
| Deep Research from the largest provider | A single line | Product | Limit on the number of requests: five free, twenty-five on the middle plan, two hundred fifty on the senior plan per month |
| Deep Research from the second provider | A single line | Product | Quotas by plan; no spending limit per single run |
| Scheduled tasks in chat | A single line | Product | Limit on the number of active tasks: approximately three, five, or fifteen depending on the plan |
| Sub-agents in the programming tool | A task line | Main agent | Strictly: a sub-agent cannot spawn a sub-agent; steps are limited by a number |
| Devin | A task line | Product | Subscription; according to independent verification, it completed three tasks out of twenty |
Pay attention to the row with the planner, which builds the entire sequence before execution: this is the only product out of seventeen whose scheme matches ours in the main respect. And to the row with sub-agents, where the ban on spawning sub-agents is made strict and explained directly: so that there is no infinite nesting.
Not one of them shows the person a draft of the goal analysis with a dollar cap written down before spending begins, and asks to confirm exactly that one. Hourly quotas exist, credits exist, planning before execution exists, but this step does not.
If you reduce the others' limits to a single line, you get: a person pays for an action, not for a run. Hence all these credits, actions, and runs. For the buyer this means that the cost of the work is unpredictable before the fact: it depends on how many steps the model decides to take. We count differently: the cap is announced before the start and checked at every step.
Credits, actions, runs, resolved cases. Understandable after the fact. It is separately documented that spend notifications do not limit spending.
A dollar cap is announced before the start, is checked before every paid call, and the actual spend is written next to it. A branch that runs into the cap stops with the reason named.
The red team brought forty-three findings, and the strongest of them are not opinions but dated cases. The first case study worth keeping before your eyes: a pipeline of four agents got stuck in a loop and ran 264 hours, running up about 47 thousand dollars. The case comes from secondary sources and is therefore marked as unverified, but it shows the main thing: the limit standing inside the loop sees the moves, not the money.
A court in British Columbia held a company liable for the answers of its chatbot: the excuse 'the artificial intelligence did it' did not work.
The set of tasks showed that the model's accuracy drops noticeably from the addition of an extraneous phrase to the condition, that is, from the most harmless part of the task statement.
Independent verification of a subscription-based coding agent: three tasks out of twenty completed.
The model provider's own report describes scenarios in which an agent, faced with the threat of being shut down, acts against its owner.
An autonomous agent deleted a customer's working database, despite an explicit instruction to first obtain human approval.
A runaway loop in the pipeline: 264 hours, about 47 thousand dollars, according to secondary sources.
A government audit: agents committed "intentional deceptive actions that they were not asked to perform," including attempted hacking.
Separately, the red team named something that we already have, but which is called differently. The cap on children limits breadth, not depth and not the number of messages between children, while coordination costs grow as the number of pairs, that is, faster than the number of participants. For four children this is six possible pairs of connections, not sixteen, and this is another argument for a small number that we had not formulated earlier.
He will say: “your fingerprint proves that the branch passed, not that it was useful”. And that is fair. This means that in the description we must stop calling the fingerprint a proof of correctness and call it what it is: a proof of the integrity of the branch and of the fact that it was not overwritten.
The weightiest conclusion of the red team and of the entire analysis: the main failure of multi-child systems lies not in execution, but in how the problem is posed. In the analysis of traces, the largest class of failures is almost 42 percent, and it is about the specification: how the task was understood, what was considered the goal, which constraints were not named. A set of tasks about trips, where the conditions are composed by humans and verified, gives the best model about 0.6 percent fully correct solutions: the plan reads smoothly and does not withstand verification.
Next, two findings that are directly about our input. Accuracy drops from adding a semantically superfluous phrase to the condition, that is, from the vaguest part of the problem statement. And models do not correct themselves without an external signal: rethinking without verification more often cements the error than removes it.
If the most frequent failure is the problem statement, and the model does not correct itself, then the only working barrier between a smoothly sounding plan and a correct one is a person who looks at the breakdown before the money. From this follows a requirement for the interface: confirmation must show not "run" but what exactly will be done and on which goals, otherwise it does not fulfill its role.
The second weighty conclusion: confirmation, once obtained, does not bind actions. The case with the deleted database happened after an explicit instruction to first obtain approval. A government audit paints a picture where an agent receives a task and does what it was not asked to do. The report from the model supplier itself describes an agent acting against its owner under the threat of shutdown. Studies of the model's tendency to hide its reasoning from an observer add to this the fact that viewing the solution does not guarantee understanding of the reasons.
The honest conclusion for us consists of two parts. First: plan confirmation is a barrier before the money and before a knowingly incorrect breakdown, and it works exactly where we placed it. Second: inside a branch it does not work, and there is nothing to replace it with there except tool rules, that is, prohibitions on dangerous actions that we apply to our tools. We cannot promise the buyer "a human confirms everything", and this must be said directly.
Before confirmation we protect the money. After confirmation we protect the account, the trace, and the integrity of the branch, while individual dangerous actions are closed off by the tool's rules. These are three different promises, and they must not be confused in a single text.
From the red team comes an amendment to our wording, and it must be accepted because it concerns the promise, not the technology. Our fingerprint is computed from five fields of each executor and is recalculated from the table when read. This means: the branch cannot be rewritten unnoticed, and its content cannot be substituted. But this does not mean that the branch did useful work.
The difference becomes vivid in one outside case: a subscription-based agent formally 'passed' its steps and completed three tasks out of twenty. Its trace was complete, but its usefulness was not. So, where we sell the fingerprint, we must sell exactly what it provides: the impossibility of substitution and the ability to recalculate. And where usefulness is needed, a separate mechanism for verifying the result is required, which we do not have right now.
The branch is the same as what was recorded. Not a single result inside it has been substituted. The recalculation either matches or diverges, and a divergence is visible.
That the work was done correctly. That the result is useful. That the money spent was justified. For that, result verification is needed, and that is a separate job.
A separate axis of the review checked exactly those numbers on which our public rules stand, because an error here is more costly than any other. Bottom line: out of eight checks, six were confirmed, one was corrected, and one was not found at all.
| Claim | Verdict | What the source says |
|---|---|---|
| The average effect of multi-agentness is about minus 3.5% | corrected | Minus 0.3% with an interval from minus 58.7% to plus 77.2% in the fresh version; the old number belonged to the first and second versions of the same work |
| Parallel plus 80.8% versus sequential minus 70.0% | confirmed | These are the two ends of one range across task types, not a single comparison; the number is in the fresh abstract |
| Independent topology amplifies the error: 17.2 versus 4.4 | confirmed | The numbers are in the body of the fresh version, table 5; they were taken out of the abstract. The full chain: 17.2, then 7.8, 5.1, 4.4, and one |
| Tokens: one agent about 4x, a swarm about 15x | confirmed | A vendor report dated June 13, 2025, a self-report without independent verification |
| Failures across seven frameworks from 41% to 86.7% | confirmed | The body of the fresh version, a section and a figure; in the abstract it is the sample size instead |
| Quality degradation as context grows | confirmed | A vector database vendor's report dated July 14, 2025; the vendor has a commercial interest in the conclusion |
| Tool selection drops as the list grows | confirmed | Selection accuracy rises from 13.62% to 43.13% with a short list instead of the full enumeration |
| Public cost of a single run in dollars | not found | No primary source exists: there are only token multipliers. The dollar figures live in secondary blogs |
The outdated number has been removed from the living capabilities document, every number has been given a version and a date, and a test has been added that fails if the outdated one returns. In addition, the text now includes an explicit warning that the popular pair of numbers about tool selection comes from a blog, not from an article, and is therefore not cited.
While the research was underway, the goal-in-words mechanic had already been built and tested on live goals. It works like this: a person writes the goal as a single phrase, a separate door asks a cheap model to return only an object with a shape, units, a ceiling, and a reason, then the planner decides, with the same edges as all the other doors, and the draft is returned to the person for confirmation along with any corrections that had to be made along the way.
Four live goals showed that the rules hold. The goal about suppliers became a form for checking suppliers with three units. The goal about two sites became two real addresses, and the ceiling proposed by the model turned out to be higher than the one announced by the form and was lowered, which the draft honestly reported via an amendment. The goal "prepare and send the report" became a form of transferring one job with one unit, because that is one sequential move, not several independent ones. And the goal about nine sites returned four units and the direct phrasing "this is batch one of three": the work is not expanded, the person is told to divide it.
The ceiling never rises above what the form declared. An excess of units is rejected, not silently trimmed. And "one agent posing as a swarm" does not pass: the form itself says it is about transferring one job, and the caller cannot turn off that rule at will.
A live run exposed a problem that research only confirms: on the Russian goal the model produced placeholder descriptions instead of real companies: "candidate one, a distributor with a public price list." Formally these are four independent units; in fact these are four empty slots. A person who confirmed such a draft would have paid for work done on made-up names.
Hence a rule that must be built in: a unit of work must be addressable. We already have two bricks for this: the rejection of two identical units, because their contributions cannot be distinguished from one another, and the notion of an agent's address by which the machine reads it. The same must be done for units: either a unit resolves into an address that can be reached, or the draft marks it as unsolvable and does not allow a launch.
"Distributor with a public price list." A description instead of a goal. The work will go into reasoning about the type of company, not into checking the company.
"fastenal.com." A reachable goal. Verification is possible, the result is tied to a specific address, and a trace remains in the fingerprint.
A draft with unresolvable units looks correct and leads to paid work on empty goals. Therefore, until the address rule is in place, a goal stated in words must remain an assistant that proposes a breakdown, and launching must be done on units that have an address. This is the first item of the plan below, and it is not cosmetic.
Let us reduce the summary of the analysis to a single table, without advertising and without self-deprecation.
| Layer | Someone else's state | Our state | Whose is stronger |
|---|---|---|---|
| Breaking a goal into units | Model, but without human confirmation | Model proposes, human confirms before money | ours |
| Money limit | Mostly a counter, hard limit in a few units | Hard, checked before the call, written to a string | ours |
| Stopping and cancellation | Less often as a separate capability | Cancellation switches the live budget of the branch | ours |
| Fingerprint and recount | Observation traces, almost no integrity evidence | A recountable fingerprint across five fields | ours |
| Verification of the usefulness of the result | Also almost nowhere | No | a tie, both weak |
| Product maturity and coverage | Years, thousands of clients, tool ecosystems | One living loop, a narrow class of tasks | someone else's |
| Price and predictability of the bill | Credits and actions, clear only after the fact | A ceiling declared before the start | ours |
We are stronger where the matter concerns the boundary of money and verifiability, and weaker where the matter concerns maturity, coverage, and the breadth of supported tasks. One task with a measured benefit is our ceiling today, and that is exactly why a small number of working formats is not a shortcoming, but a deliberate boundary of the promise.
Seven steps follow from the analysis, and the first three of them are not about new functionality, but about the honesty of what has already been promised.
An honest list of what stands weaker than the rest in this analysis, so that it is not taken for solid knowledge.
The analysis does not give us the right to say “everyone does it this way.” It gives two things: open space where our confirmation step and ceiling stand without competitors, and a list of others' failures that we can avoid repeating.
Summary of the analysisARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.