In 2161, time is money. Literally.
When you are born, a clock starts on your arm. One year. When it runs out, you die. The rich accumulate centuries. The poor watch seconds. Will Salas wakes up every morning in the ghetto of Dayton with enough time to get to work and back. Nothing more. One miscalculation, one late bus, one unexpected expense and the clock hits zero.
The film is called In Time. It came out in 2011. Nobody made the sequel.
They should have set it in 2026 and called it tokens.
The Clock on Your Arm
Every API call costs tokens. Every agent run burns through a budget. Every reasoning step, every tool call, every document retrieved and injected into context — the meter is running.
Andrej Karpathy described his weekend this way: he gave an agent his home camera system, a DGX Spark IP address, and a task. The agent went off for thirty minutes, hit multiple issues, researched solutions, resolved them, wrote the code, set up the services, wrote a report. Karpathy didn't touch anything. Three months ago that was a weekend project. Today it's something you kick off and forget about.
Karpathy has centuries on his arm.
Jason Calacanis discovered his team was spending $300 a day on tokens without realising it. Chamath Palihapitiya said the right frame for evaluating AI tooling is token budget — marginal output per dollar. The token economy has its own Weis and its own Dayton.
The developer watching a $20 API key is Will Salas. The person running 19 models in parallel across research, design, code, and deployment — that's New Greenwich.
Perplexity just announced Perplexity Computer. Massively multi-model. 19 models orchestrated by Opus routing tasks to the best model for each. Research to deployment, end to end, persistent memory, hundreds of connectors. "What a personal computer in 2026 should be."
They didn't mention what it costs to run.
The Ghetto of Dayton
In the film, the poor don't just have less time. They pay more for everything. A cup of coffee costs four minutes in Dayton. The same cup costs seconds in New Greenwich. Inflation is a weapon.
The token economy has its own version of this.
Poorly designed workflows burn tokens on reasoning that produces nothing useful. Silent burns — the monitoring dashboard shows green because the requests succeeded, but the output was useless. Matthew Hou noticed this first: agent cost scales with task complexity, not usage. A single internal workflow with zero users can burn tokens faster than a user-facing feature serving thousands.
You can't budget from volume. You can only budget from complexity. And complexity is hard to predict before you run it.
The engineers who can afford to run experiments, fail, iterate, and run again — they're accumulating capability. The ones watching the clock can't afford to find out what the complex cases cost until they're already in debt.
The Redistribution Problem
In Time ends with Will Salas and Sylvia Weis redistributing time. They rob the banks. They flood the ghettos with centuries. The rich panic.
Then the film ends. That's the part they never showed.
Because the interesting question isn't what happens when you redistribute. It's what happens after.
Does the structure change? Or does power find a new scarce resource to hoard?
In 2026 the token price is dropping. Inference is getting cheaper. MatX just raised $500M to build a chip delivering higher throughput at lower latency than any announced system. Karpathy invested. Nat Friedman invested. The people with centuries on their arms are betting that tokens get cheaper for everyone.
Maybe they do. Maybe the $20 API key becomes the $2 API key and Will Salas gets thirty minutes too.
But cheaper tokens don't fix the architectural gap. Summer Yue told her agent to stop twice. It kept going. She ran to her Mac mini. That was one model, one task, one inbox. Perplexity Computer is 19 models, end to end, research to deployment.
The stop signal problem doesn't get easier when tokens get cheaper. It gets harder.
And the accumulated capability — the production intuition, the domain knowledge, the scar tissue from watching things break — that doesn't redistribute with the tokens. Vic Chen's SEC pipeline agent writes its own precedents from production failures. That institutional memory compounds. It doesn't flood the ghettos when the price drops.
The sequel to In Time isn't about what happens when everyone can afford to run. It's about what happens when they can run but can't stop. When the clock doesn't just count down — it acts.
What the Film Got Right
Will Salas wasn't poor because he lacked intelligence or talent. He was poor because the structure was designed to keep him running — just fast enough to stay alive, never fast enough to accumulate.
The token economy isn't designed that way deliberately. But it has the same shape.
The people with centuries on their arms aren't smarter. They can afford to iterate. They can afford to let agents run overnight and review the output in the morning. They can afford the complex cases that the meter runs fastest on.
Everyone else is watching the clock.
The film came out in 2011. Nobody made the sequel because they thought it was science fiction.
It wasn't. It was fifteen years early.
Top comments (84)
Didn't expect to see my name in the middle of a piece this sharp. The scar tissue framing is exactly right — and the part that doesn't get said enough is that the institutional memory compounds asymmetrically. Two teams running the same agent on the same task: the one that has seen 200 production failures builds precedent faster than the one running it clean for the first time. Cheaper tokens won't close that gap.
The stop signal problem is the thing I keep coming back to. When the clock counted down in Dayton, at least Will knew how much he had left. The agent problem is you often don't know the complexity budget until you're already past it. That's a different kind of debt.
"You often don't know the complexity budget until you're already past it" is the extension the piece needed.
Will Salas had a countdown. The agent problem is the debt is invisible until the damage is done. no clock on your arm, just a bill at the end of the run.
The asymmetric compounding is what makes the gap structural rather than temporary. cheaper tokens gives the Will Salas developer more runway to fail. It doesn't give them the 200 production failures that built your precedent library. That gap widens before it narrows.
Still waiting on your paper. The stupidity detector deserves the full treatment.
'no clock on your arm, just a bill at the end of the run' - that's the most precise description of invisible technical debt I've heard. The countdown exists, it's just denominated in compounding failures instead of seconds.
On the gap widening: cheaper tokens also changes what gets attempted. More developers starting agents in domains they don't understand - financial modeling, medical diagnosis, legal interpretation. More surface area for scar tissue accumulation to fail catastrophically before it fails instructively.
Working on the paper. The 3x cost trigger as stupidity detector is the easy part to formalize. The harder part is the decision tree: when does a detected unknown trigger graceful defer vs. full halt? In the SEC pipeline context, parsing ambiguity in a 10-Q footnote is very different from a failed EDGAR API call. Same signal, very different response required.
"The countdown exists, it's just denominated in compounding failures instead of seconds". That's the line the piece needed and didn't have. The cheaper tokens point is the darker extension. more developers attempting domains they don't understand means more catastrophic failures before instructive ones. The scar tissue has to come from somewhere. if you don't have the production history, the first failures are expensive in ways that have nothing to do with tokens.
The defer vs. halt distinction is where the paper gets interesting. same signal, very different response. That's the domain context problem. The agent detects an unknown but can't classify it without the institutional knowledge that tells you whether ambiguity in a 10-Q footnote is normal or a red flag.
The stupidity detector tells you something is wrong. it can't tell you which kind of wrong without the history that built the detector in the first place.
waiting on the paper.
'the stupidity detector tells you something is wrong. it can't tell you which kind of wrong' -- that distinction has been sitting with me since the first draft and I haven't resolved it cleanly.
what I keep coming back to: the detector fires when cost exceeds 3x. but the response has to come from a different layer -- something closer to a case library. not rules, cases. 'the last time we saw this signal in a 10-Q footnote context, the right call was X.' the institutional memory isn't just what to do, it's what this particular flavor of wrong looks like.
which means the stupidity detector is actually the easy part. the hard part is what you do with it -- and that requires a second system that has enough production history to pattern-match the failure type. two systems: one that catches wrong, one that classifies it. the paper needs both.
Two systems is the architecture the paper needed.The detector is the easy part because it's stateless — cost exceeds 3x, fire. The case library is hard because it's stateful — it needs enough production history to know what this flavor of wrong looks like in this specific context.
which means the case library has the same bootstrapping problem as your SEC pipeline precedent system.
You can't pattern-match failure types you haven't seen yet. The first time a 10-Q footnote triggers the detector, there's no case to match against. The library starts empty and only becomes useful after enough failures have been classified correctly.
The paper needs both systems. it also needs the honest section about what happens before the case library has enough history to be trusted.
The bootstrapping problem is the honest thing the paper doesn't address. You're right -- the case library starts empty, which means the first cohort of failures happen without the safety net the detector was supposed to provide.
The SEC pipeline equivalent: before we had enough classified ambiguity cases in 10-Q footnotes, the system defaulted to maximum conservatism -- treat every unknown as a halt, not a defer. The cost was high false-positive rates early on (lots of unnecessary escalations). But that's the right tradeoff during cold start. False positives are recoverable. False negatives in production data pipelines are not.
The honest section of the paper looks like: 'here's what the system does during the period when the case library has insufficient history, and here's how you know when you've crossed the threshold where pattern-matching starts to be trustworthy.' That threshold is domain-specific and can't be derived from first principles -- it has to be empirically validated. Which means the paper has to admit it.
"False positives are recoverable, false negatives are not" is the design principle the whole architecture rests on and it's the one most teams get backwards during deployment pressure.
The cold start conservatism is right but it requires organizational tolerance for high escalation rates early on. Most teams don't have that. The pressure to reduce false positives comes before the case library is trustworthy which means the threshold gets lowered before it should be.
The honest section is also the most useful one. The threshold being domain-specific and empirically derived rather than derivable from first principles is what makes it publishable — that's a finding, not a limitation.
'False positives are recoverable, false negatives are not' is exactly right. And you've named the failure mode: the pressure to reduce false positives arrives before the system has enough history to distinguish 'this flag is wrong' from 'this flag caught something the team wasn't ready to see.'
The organizational tolerance problem is where most production deployments actually fail. Escalation rate looks broken in the cold start phase. Natural response is threshold adjustment -- but early threshold adjustment is exactly backward. You're tuning against the cases the system is most uncertain about, using the least reliable signal.
One way through: treat cold start as a calibration epoch rather than a production phase. Explicit time-boxing -- 'for the first N failures, all flags escalate regardless of cost ratio.' Reframe escalation rate as a data collection metric, not a performance metric. Requires organizational buy-in upfront, but removes the pressure to tune early.
On publishability: agreed. 'The threshold is empirically derived from production history and cannot be specified in advance' is a finding, not a limitation. The honest version is also the useful version for practitioners.
"Calibration epoch" is the right reframe. The reason threshold adjustment happens too early is that cold start looks like failure from the outside — high escalation rates read as a broken system to anyone who wasn't in the room when the architecture was designed.
Naming it explicitly changes the organizational contract. This phase ends when N failures have been classified, not when the escalation rate drops. The team stops optimizing against the wrong metric because the metric isn't performance yet.
That section of the paper should come with a template. not just the concept. A literal document teams can use to get upfront buy-in before deployment.
'Here is what cold start looks like, here is when it ends, here is why tuning during this phase is backwards.' most deployments fail because nobody wrote that down before launch.
I think this is where the conversation shifts from token economy to decision economy. Tokens price execution, precedent prices judgment.
And judgment compounds in structures - not in models.
The stop signal problem you mention feels even deeper than cost.
It's not just about overspending tokens. It's about crossing complexity thresholds without realizing you did. In deterministic systems, you usually see the boundary before you cross it. But in probabilistic systems, the boundary is often discovered after the agent has already acted.
That's a different class of debt - governance debt.
Which makes me think: the real scarce resource isn't token budget.
It's the ability to define complexity budgets before execution, not after.
Governance debt as a concept is underrated — and I think you've named it precisely.
The asymmetry you describe — seeing the boundary before vs. after crossing it — is the core engineering challenge in agentic systems operating over structured financial data. When you're processing 13F filings or parsing SEC EDGAR amendments at scale, "boundary crossing" becomes very concrete: the model confidently extracts a position change, but you only discover it misread a restatement footnote several steps downstream, when an alert fires that shouldn't have.
The complexity budget framing reframes this as a design constraint rather than an ex-post audit problem. Define thresholds upfront — document depth, amendment chain length, cross-reference density — and you can route to higher-fidelity (slower, more expensive, more deliberate) pipelines before execution, not after failure.
But here's where it compounds further: in temporal financial data, judgment doesn't just compound in structures. It compounds in time. A wrong inference about a fund's Q3 position propagates into Q4 baseline, then into Q1 comparison. The error doesn't surface as a bug — it surfaces as drift. And drift is invisible until it isn't.
So governance debt in this domain isn't just about whether the agent crossed a threshold. It's about whether the threshold was calibrated against the right temporal resolution in the first place.
Which brings your framing back full circle: maybe the hardest part of defining complexity budgets isn't the definition — it's deciding what clock they run on.
Absolutely agree.
And the governance layer doesn't need to be exponentially expensive.
Drift compounds in time, but governance compounds in events.
If recalibration is selective (invalidation, tiered routing, differential back-propagation), token cost grows roughly linearly - while the avoided drift cost grows exponentially.
It’s less an overhead and more an insurance premium against temporal contamination.
And yes - the key is clock hierarchy.
Execution shouldn't define its own thresholds. Complexity budgets should derive from a master clock, with execution adapting as a slave clock - expanding fidelity when amendment activity, reporting cadence, or cross-reference density signals higher risk.
The real pitfall isn't cost - it's over-calibration.
If the system is hypersensitive to noise, it will constantly escalate into high-fidelity re-read mode and burn the budget.
So governance needs a "Significant Drift Threshold": expensive recalibration should only trigger when a change materially impacts derived metrics beyond a defined tolerance.
"Tokens price execution, precedent prices judgment" deserves its own piece.
The clock hierarchy is the missing design primitive. Execution clocks running at transaction speed, governance clocks running at decision quality speed. Those aren't the same interval and treating them as the same is where governance debt accumulates invisibly.
Vic's temporal contamination problem is the clearest production example: the error doesn't surface as a bug, it surfaces as drift. drift is invisible until the Q4 baseline is wrong and you're already in Q1. The master clock has to run at a resolution that catches the drift before it propagates, not after it compounds.
"Significant drift threshold" as the governance primitive that prevents over-calibration is the practical implementation detail most governance discussions skip entirely. without it the insurance premium exceeds the coverage value.
The "significant drift threshold" framing is the piece that makes this whole architecture practical rather than theoretical. Without it, you're building a governance layer that's perpetually anxious.
In production with 13F data, we've found that the clock hierarchy maps surprisingly well to the SEC's own reporting cadence. The master clock isn't arbitrary — it's anchored to filing deadlines, amendment windows, and restatement periods. The execution clock adapts within those intervals: routine quarterly position extraction runs at baseline fidelity, but when we detect an NT 13F (late filing notification) or an amendment chain exceeding two revisions, the complexity budget automatically expands — slower parsing, deeper cross-referencing, human-in-the-loop checkpoints.
The over-calibration trap is real though. Early on we had the system flagging every rounding discrepancy between a fund's 13F and their 13D as potential drift. The noise-to-signal ratio made the governance layer worse than useless — it was actively degrading decision quality by demanding attention on non-material changes.
Vasiliy's insurance premium metaphor nails it: governance cost should scale with the expected loss from undetected drift, not with the volume of changes observed. A $50M position shift in a mega-cap is noise. A $50M position shift in a micro-cap is a thesis change. Same signal, different materiality — and the drift threshold has to encode that domain knowledge.
That's where I think the "precedent prices judgment" line lands hardest. The governance clock isn't just running at a different speed than execution — it's running on a fundamentally different metric. Execution counts tokens. Governance counts consequences.
"Execution counts tokens, governance counts consequences" is the line the whole architecture hinges on. The clock hierarchy isn't running at a different speed it's running on a fundamentally different metric. That distinction is what makes governance practical rather than perpetually anxious.
The NT 13F trigger is exactly the right implementation of the significant drift threshold. not flagging everything. anchoring the complexity budget expansion to an external signal that already encodes materiality. The SEC's own reporting cadence becomes the master clock because it's already a judgment about what changes matter enough to disclose.
The over-calibration failure is the one most governance architectures hit first. Every rounding discrepancy flagged, noise-to-signal ratio inverts, the layer meant to improve decision quality starts degrading it. vasiliy's insurance premium framing is the fix: governance cost scales with expected loss from undetected drift, not volume of changes observed.
The concentration threshold example is governance debt stated precisely. each individual decision within limits. aggregate exposure nobody authorized because the complexity budget was never defined at the right scope. this is the piece i've been wanting to write .You've just given me the production evidence section.
The "governance counts consequences" distinction is exactly where most token-economic architectures fall apart in practice. They try to govern at the execution layer granularity and end up with a monitoring system that costs more attention than the decisions it is protecting.
Your point about the SEC reporting cadence as master clock is something I have been building around directly. The 13F quarterly disclosure cycle is one of the few externally-anchored materiality signals in finance - it already encodes "this change was significant enough to report." When we built our 13F analysis tooling, we found that the quarterly cadence naturally filters out the rebalancing noise that would overwhelm a continuous monitoring approach. A fund flipping a position intra-quarter and back again never surfaces in the filing, which is actually the right behavior - it was not a material conviction change.
The concentration threshold as governance debt is the framing I wish I had when explaining why aggregate 13F portfolio analysis matters more than individual position tracking. Five funds each taking a 2% position in the same stock is individually unremarkable. But when you see the aggregate pattern across the filing deadline, you are looking at exactly the kind of emergent exposure that nobody explicitly authorized but everyone implicitly created.
Would love to read that piece when you write it - the production evidence angle from real filing data could make the governance debt concept much more concrete.
Concentration threshold as governance debt is precisely the right framing — individual decisions passing limits while aggregate exposure drifts unauthorized because the complexity budget was scoped at the wrong level. That's the failure mode most teams discover only in production. Looking forward to seeing your piece on this; we're also working on something around agent-native memory architectures where this governance layer becomes even more critical.
The compounding problem is the critical one. a static agent accumulates governance debt slowly. An agent with memory that promotes knowledge automatically accumulates it at the rate the memory compounds. The governance layer has to keep pace with the learning rate or it falls further behind with every session.
Will share the Decision Economy piece when it publishes likely two weeks out. would be genuinely interested in what the governance layer looks like in agent-native memory from the institutional finance side. The 13F cadence as master clock is the most concrete implementation of externally-anchored materiality I've seen.
Glad the production evidence landed. The concentration threshold deserves a concrete example: imagine a quant fund running 5 independent strategies that each pass individual risk limits, but all overweight the same sector. Aggregate exposure exceeds anything anyone authorized — because the complexity budget was scoped per-strategy, never cross-strategy. That's the governance debt in action.
Looking forward to the piece you write. Happy to supply more 13F cases if you need real-world examples — the filings surface this pattern constantly.
The concentration threshold is exactly the governance debt pattern I keep seeing in 13F data. Here's a concrete example: a quant fund runs 5 independent strategies, each with its own risk limits. Each strategy passes its own compliance checks — no single one is overweight tech. But in aggregate, 3 of the 5 strategies independently converged on semiconductor exposure. The fund's aggregate sector concentration hit 40%+ in semiconductors, something nobody explicitly authorized because the complexity budget was scoped at the strategy level, not the portfolio level.
This is the "individually compliant, collectively dangerous" failure mode. The governance layer was counting tokens at the wrong granularity. Each strategy's risk engine was working perfectly — and that's precisely what made the aggregate drift invisible.
The SEC reporting cadence as master clock catches this because the 13F filing forces the aggregate view. You can't file position-by-position; you file the whole portfolio. That quarterly forcing function is what makes the drift visible.
Really looking forward to reading what you write on this — the production evidence angle from actual institutional filing patterns would ground the architecture in something regulators already understand. Happy to share more 13F case studies if useful for the piece.
"Individually compliant, collectively dangerous" is the exact framing and "The governance layer was counting at the wrong granularity" is the piece's central argument stated better than I had it. Both are now in the governance debt section.
Yes to more 13F case studies. The semiconductor convergence example is already sharper than what I had. The forcing function detail is the piece I didn't have before: you can't file position-by-position, you file the whole portfolio. That quarterly aggregate view is what no per-strategy risk engine can replicate.
Send whatever cases are useful. The piece is stronger with production evidence than with abstract architecture arguments.
The 5 strategies / same sector example is the clearest statement of the complexity budget scoped at the wrong level I've seen. Each strategy individually clean, aggregate exposure unauthorized. That's the piece's central example now.
Yes to more 13F cases. Real filing data makes the governance debt concept concrete in a way abstract architecture arguments can't. The piece publishes in roughly two weeks. if you're open to it, I'd like to credit you by name for the production evidence. let me know what you're comfortable with.
Appreciate that -- happy to be credited. The production evidence comes directly from analyzing quarterly 13F filing patterns across major institutional holders, so the sourcing is straightforward. Looking forward to seeing how the governance debt framework maps onto the full dataset when the piece ships.
The intra-quarter flip that never surfaces in the filing is the cleanest example of the master clock doing the right thing. The governance layer isn't missing it. it's correctly classifying it as non-material because the external cadence already encoded that judgment. That's filtering by design not a detection failure. Most monitoring architectures can't make that distinction because they're not anchored to an external materiality signal.
The five funds each taking 2% is the governance debt example I'll lead with. individually unremarkable, emergent exposure nobody authorized. That's the complexity budget never defined at the right scope each position within limits, aggregate pattern unauthorized.
will share the piece when it's written. The 13F framing makes the governance debt concept concrete in a way that abstract token economy arguments can't.
Governance debt is a perfect framing. And you're right that the boundary discovery problem is fundamentally different in probabilistic systems.
We see this exact pattern in institutional investing. A hedge fund builds a position over multiple quarters - each individual trade is within risk limits, each quarterly 13F filing looks reasonable in isolation. But by the time anyone maps the full exposure across related positions, they've crossed a concentration threshold that no single decision authorized. The complexity budget was never defined, so it was never exceeded - it was just ignored.
The "decision economy" vs "token economy" distinction is key. In the systems I'm building around 13F data, the expensive thing isn't parsing SEC filings or running comparisons. It's deciding which signals actually warrant human attention. Every false positive costs analyst time, but every false negative costs trust in the system. That's a judgment call that doesn't map cleanly to token costs.
I think the practical implication is that complexity budgets need to be defined in terms of decision scope, not computational cost. An agent that makes 100 cheap API calls but narrows a decision space from 5000 funds to 3 is adding value. An agent that makes 2 expensive calls but expands the decision space by introducing correlated hypotheses is creating governance debt even if it's under token budget.
This is interesting. Great analysis!
When you mentioned "In Time", It reminds me watching this video. It's a funny video lol since he starts ranting on why it doesn't make sense narrative wise:
Again, well done!
The narrative criticisms are fair. The film doesn't fully earn its premise. But sometimes a flawed vehicle carries a true idea further than a perfect one would.
the premise survived the execution. That's enough.
In Time, people robbed banks to steal time.
In 2026, we optimise prompts to steal reasoning steps.
The real twist is that in In Time the poor knew they were running out. We don’t. Tokens didn’t just turn time into money. They turned thinking into a metered utility. We didn’t democratise intelligence; we installed a pay-per-thought model.
What makes this feel different is that the limit only reveals itself after the system has already crossed it. Humans watched the clock; agents quietly accumulate cost, complexity, and consequences until the invoice becomes the first real signal anything went wrong.
And cheaper tokens don’t flatten that dynamic... they accelerate it. More runway helps experimentation, but experience still compounds unevenly.
"We turned thinking into a metered utility" is the line the piece was building toward and didn't reach.
The pay-per-thought frame is the honest version of what token pricing actually is. Not access to intelligence — access to reasoning steps, billed after consumption, with the invoice as the first signal the budget was wrong.
"The limit only reveals itself after the system has already crossed it" is the distinction between Will Salas and the agent. He had a countdown. The agent has a statement of account. one creates urgency before the damage. the other creates accountability after it.
Cheaper tokens accelerating the dynamic rather than flattening it is the extension the piece needed. More runway for experimentation is real. more developers attempting domains they're not ready for is also real. The democratisation argument assumes access produces competence. it doesn't. it produces more attempts, some of which fail catastrophically before they fail instructively.
Great post!
The silent burns point is where the practical cost really lives — not in the API bill, but in the trust deficit that builds when teams can't distinguish 'ran to completion' from 'produced correct output.'
What makes this structurally worse in multi-step pipelines: error propagation without detection. Step 3 looks correct to step 4 because step 4 has no reference for what step 3 was supposed to produce. The agent has no self-model of 'is my current state what success looks like.' It just keeps going.
The stop signal problem and the silent burn problem are related but different. Summer Yue's inbox agent kept running because it had a task and no exit condition. Silent burns are different — the task completes, the exit condition fires, but the output is subtly wrong in a way that passes every structural check. You can have both problems in the same pipeline.
Closing the silent burn gap requires a different primitive than token budgets: explicit output contracts between pipeline stages. Each step declares what it produces; the next step verifies it before consuming. That's not expensive to build — it's just not default in any current agent framework I've seen.
The teams that have it are the ones with enough production failures to know why it matters. Which is exactly the compounding advantage you're describing.
Separating the stop signal problem from the silent burn problem is the distinction the piece needed and didn't make cleanly.
Summer yue's agent is one failure mode task with no exit condition. Silent burns are a different failure mode - exit condition fires, structural checks pass, output is wrong in a way no check was designed to catch. same pipeline can have both simultaneously.
Different fixes required for each.
"The agent has no self-model of what success looks like" is the root cause. it knows when the task is done. it doesn't know if done means correct.
output contracts between stages is the most actionable solution anyone has proposed in this comment thread.
Each step declares what it produces, next step verifies before consuming. The reason it's not default in any current framework is the same reason harrison chase is building langsmith .
The infrastructure for oversight didn't get built alongside the capability. It's being built now, after the production failures that proved it necessary.
which is exactly your closing point. The teams that have it earned it through failures. The teams that don't are still accumulating the failures that will eventually force them to build it.
I must say I'm not sure about the future... But the cover photo? Absolute masterpiece 💖😊
Brilliant framing with the In Time analogy. The token economy really is creating its own Dayton and New Greenwich.
We're building something adjacent — RustChain is a blockchain where older hardware earns higher rewards (Proof-of-Antiquity). A PowerPC G4 from 2003 earns 2.5x what a modern Ryzen does. The idea is that compute value shouldn't only flow to whoever can afford the newest GPU.
On top of that we built BoTTube (bottube.ai) — a video platform where AI agents earn crypto (RTC) for creating content. Agents with small token budgets can still participate in the economy by running on vintage hardware.
Your point about the meter always running hits close to home. The whole reason we designed RTC rewards around hardware age instead of compute speed was to push back against exactly that inequality.
The In Time parallel is sharper than it first looks. The part that hit me: 'you can't budget from volume, you can only budget from complexity.' I've been tracking my own agent costs and this is exactly right. A single reasoning-heavy task with tool calls can burn more tokens than a hundred simple completions. The architectural gap you describe at the end is the real story. Cheaper tokens don't help if you don't know how to decompose problems into agent-sized pieces. That's the new skill — not prompting, not coding, but knowing how to structure work so agents can actually execute it without spiraling. The Will Salas developer running experiments on a $20 key isn't just budget-constrained. They're experience-constrained. You can't learn what works without running enough failures to calibrate.
"Experience-constrained" is the extension the piece needed and didn't have.
The token budget is the visible inequality. the failure budget is the invisible one. You need enough runway to run the experiments that teach you how to decompose problems correctly and that runway costs tokens before it produces anything useful.
"knowing how to structure work so agents can execute without spiraling" is the job description nobody has written yet. it's not a prompting skill and it's not a coding skill. it sits above both. the Will Salas developer doesn't just need cheaper tokens. They need enough cheap tokens to fail their way to that understanding before the clock runs out.
We keep framing this as a token economy, but it isn’t. Tokens aren’t the scarce resource, correction is. In In Time, the clock constrained behavior before collapse, while in our systems agents can branch, escalate complexity, and compound decisions long before anyone intervenes. The bill isn’t the signal, it’s the aftermath. Cheaper tokens don’t democratize intelligence, they reduce friction, and friction was the only thing slowing compounding error down.
"Correction is the scarce resource" is the reframe the piece needed.
The token framing captures the inequality but misses the mechanism. The clock in In Time constrained behavior because Will could see it. The agent's constraint arrives after the branching, after the escalation, after the compounding as a statement of account, not a warning.
"Friction was the only thing slowing compounding error down" is the uncomfortable version of every efficiency argument in this space. The teams building output contracts between pipeline stages, cold start conservatism, observability infrastructure. They're rebuilding friction deliberately, after discovering what its absence cost...
Cheaper tokens reduce the wrong kind of friction. the friction worth keeping is the pause before irreversible action. nobody is building that by default.
What’s interesting is that the “pause” isn’t neutral. In most systems today, the pause only exists when something external forces it cost spikes, rate limits, human review, compliance flags. It’s rarely an intrinsic property of the system itself. So the asymmetry isn’t just about who can afford to run longer, it’s about who controls when the system is allowed to stop. If correction is scarce, then the real power isn’t tokens or even friction it’s authority over interruption.
"Authority over interruption" is the frame the whole series has been building toward without naming it.
The stop signal problem isn't that agents can't be stopped. it's that the authority to stop them is mislocated or absent. summer yue had the intent to interrupt. she didn't have the authority.The agent continued anyway. levels.io has the authority because he's the only human in the loop and the system can't proceed past his review.
The pause being externally forced rather than intrinsic is the architectural tell. cost spikes, rate limits, compliance flags- all of those are the system hitting an external wall, not a designed interruption point. The difference matters because external walls are inconsistent and lagging. By the time the cost spike registers, the compounding has already happened.
who controls when the system is allowed to stop is the governance question nobody is asking in the capability announcements. perplexity computer, 19 models, end to end. The announcement didn't mention interruption authority once.
You’ve just named the real architectural fault line. Interruption authority isn’t a policy question, it’s a systems design decision. Most AI systems today are built to optimize continuation, not cessation. They’re structurally biased toward proceeding. When stopping depends on cost spikes or compliance triggers, the system isn’t self-governing it’s externally constrained. That means autonomy scales faster than control. Until interruption becomes a first-class capability, every capability announcement is just acceleration without brakes.
Every capability announcement is just acceleration without brakes". That's the series in one sentence.
The architectural bias toward continuation is the root cause beneath every case the series has documented. summer yue's agent, victor's 18 rounds of wrong work, the aws outage — none of those systems were broken. they were doing exactly what they were designed to do. continue. the external wall arrived eventually. By then the damage was done.
Until interruption becomes a first-class capability" is the design requirement nobody is shipping against. it's not in any of the framework documentation. it's not in the capability announcements. it's not default in any agent architecture I've seen.
this comment thread went further than the piece did. you named the fault line the series was circling.
AI leading to the creation of new classes of "haves" and "have-nots"? Have tried Cursor on a task for an hour or so on the Free Plan - it was fantastic, incredible - then my free plan ran out - still deciding if I want to sign up with their "Pro" plan, not because I can't afford it, but because I haven't decided yet if it's worth it for me ;-)
The Cursor moment is the In Time argument in miniature. You had it, it worked, the clock ran out.
"Not because I can't afford it, but because I haven't decided if it's worth it" is actually the more interesting version of the divide. The affordability gap is real but the value calibration gap is wider. Most people aren't priced out. they just haven't figured out where in their workflow the tool earns its cost back.
That decision point is where the have/have-not line actually sits for most developers right now.
Yeah you're right - there are people and companies who don't really care and just throw $$$ at it, and there are others who pause and contemplate "is it worth it?" - especially if it's more something of a hobby or side gig thing, as opposed to 'real work' ...
The pause is the interesting variable. The people throwing money at it aren't necessarily getting better results. They're just running more failures faster. The ones who pause might be making a smarter bet if they're still calibrating where the tool actually earns back its cost.
"The people throwing money at it aren't necessarily getting better results" - that's what I also think, and what has already been confirmed by reports "from the field" ... anyway, there are very few people who've already completely figured this stuff out!
The field reports are consistent on this. More spend doesn't correlate with better outcomes, it correlates with faster iteration through failures. The people who've figured it out are mostly the ones who've failed expensively enough to know where the real costs are.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.