You Authorized the Goal at 9 AM. What Is the Agent Allowed to Do Until 5 PM?

Most agent releases ask you to care about a benchmark table. This one has a number in it that is actually about your day: eight hours.

On 13 August 2026 WRITER announced Palmyra X6, its new flagship model, alongside a rebuilt WRITER Agent and new governance and reporting in AI Studio. WRITER's post says Palmyra X6 "can run unattended on a single goal for up to 8 hours". WRITER's developer documentation says the same thing in slightly more precise language: Palmyra X6 "can hold a single objective for up to 8 hours without supervision, planning, executing, verifying output, and delivering finished work rather than a draft that needs another pass".

Read that as a reliability milestone and it is impressive engineering. Read it as a governance statement and it says something else. It says the gap between the moment a person authorizes something and the moment that person next looks at it can now be most of a working day.

What WRITER actually shipped

Let me stay close to the sources, because this is a subject where paraphrase inflates fast.

WRITER says Palmyra X6 is engineered for high volume personalization, research and content work, that per task cost and latency are roughly halved versus the previous generation with no measured quality regressions, and that it is priced at $2.00 per million input tokens and $8.00 per million output tokens with a 1M token context window. WRITER's documentation names it the default model for WRITER Agent and describes it as co developed with the product's orchestration layer.

On the agent, WRITER lists adaptive reasoning that adjusts approach to task complexity, execution of high volume tasks in batches or by delegation to sub agents, more reliable recovery from errors with fewer interruptions, better ordering of tool calls, a clearer progress view, structured questions to the user when clarification is needed, and visualisation of actions from connected tools inside the session. WRITER reports that the agent completes tasks 44 percent faster and at 41 percent lower cost per task on average across all models tested, and 52 percent lower cost with 48 percent better speed and 10 percent better quality when paired with Palmyra X6.

Those percentages, the capability scores in WRITER's documentation, and the median cost per finished task of $0.12 on a sample of 22 production customer tasks are all vendor supplied measurements from WRITER's own internal evaluation. I am reporting them as WRITER's numbers, not as independent findings, and I am not building any argument on top of them.

The part I care about is the capability list in the documentation, because it describes what an execution path can contain. WRITER documents connector driven tasks including querying CRM records, searching Slack messages and updating documents through prebuilt and custom connectors. Multi step automation that breaks complex requests into sequenced tool calls across multiple systems. Grounded responses pulling from Knowledge Graphs, documents and connector data. Playbooks executed end to end. Sub agents, described as delegating work to spawned sub agents and merging results back into the primary workflow. MCP tool use, described as discovering and calling external tools through MCP connectors. And long horizon execution, described as sustaining multi hour objectives with planning, self testing and correction loops.

Eight hours is not just a reliability milestone

Here is the shift that I think is being underrated.

An interactive assistant hands control back constantly. You ask, it answers, you look, you decide what happens next. Control returning to a human is not a designed safety feature in that setup. It is a side effect of the model not being able to do very much before it needs you again. Every one of those handbacks is an unplanned review.

A long horizon agent removes most of them. Not maliciously, and not by disabling anything. It removes them by being good enough at planning, tool ordering and recovery that it no longer needs to stop. WRITER states this directly as a benefit, and it genuinely is one: "Fewer interruptions when faced with errors. WRITER Agent can recover more reliably from issues and is better at consistently calling the right tools in the right order."

Moona Intelligence's inference, clearly labelled as inference and not as anything WRITER said: an agent that stops less often also produces fewer natural moments in which a person reconsiders what it is doing. The oversight most teams actually rely on is incidental rather than designed. It is the interruption, the clarifying question, the failed tool call that makes somebody look at the screen. Improving reliability improves outcomes and quietly removes the accidental review layer at the same time. Both things are true.

One objective can produce a great many actions

A person authorizes an objective. What follows is not the objective. It is an execution path, and the path is discovered as the agent goes.

Using only what WRITER documents: a single request can be broken into sequenced tool calls across multiple systems, run in batches, delegated in part to spawned sub agents, grounded against Knowledge Graph and connector data, extended through MCP tools discovered at runtime, checked by self testing, and revised through correction loops when something fails. Every one of those is a legitimate product capability that customers are buying on purpose.

Stack them across a multi hour run and the arithmetic is uncomfortable in a completely ordinary way. The objective was authorized once. The individual operations that satisfy it were selected afterwards, by the system, on the basis of what it found while working. Nobody has to behave badly for the set of executed actions to end up much larger and much more specific than the thing a human agreed to.

To be explicit, because this is where articles like this usually cheat: none of that is evidence of unsafe behaviour. WRITER has not published an incident and I am not implying one. WRITER also does not hand an agent unrestricted access to anything. What an agent can reach depends on which connectors an organisation has configured, how those connections are set up, and what the connected system itself permits for that account. WRITER additionally ships admin side controls in this release: a centralised view of sessions, playbook and skill runs, active users, deliverables and token usage, filterable by team, billing group or seat, plus real time token consumption with alerts and the ability to block consumption above set limits.

Note what those controls are denominated in. Spend and usage. That is a real lever, and it is the lever enterprises asked for, because uncapped token spend is the thing currently stopping agents from reaching production. It is not the same lever as "which operations may execute against which systems, seven hours into a run".

So when does the original authorization stop applying?

This is the conceptual centre and I do not think the industry has an agreed answer.

Ask yourself what an authorization is even attached to. The objective, so that anything genuinely in service of the goal is covered? Each individual action, evaluated on its own merits at the moment it executes? Specific named resources, so the boundary is the system rather than the intent? A session, so authority ends when the run ends? A period of time, so authority expires whether or not the work is finished? Some combination of those?

Most deployments today answer this implicitly rather than deliberately, and the implicit answer is usually the first one: the goal was approved, therefore the work serving the goal is approved. That is a defensible position for a three minute task. It is a much larger claim when the same sentence covers eight hours of self directed execution across CRM records, chat history, documents and externally discovered tools.

I am not going to pretend there is one correct answer here, and I am certainly not going to answer it with product architecture. The point is narrower and I think it holds: the answer is currently being chosen by default rather than by decision.

Sub agents make inheritance a real question

WRITER documents that the agent can delegate work to spawned sub agents and merge their results back into the primary workflow. WRITER scores that capability at 0.86 in its own evaluation. That is the extent of what the documentation establishes, and I am not going to speculate beyond it about how WRITER implements permissions for delegated work.

The category question stands on its own, though, and it applies to every framework that supports delegation. If a primary agent spawns a sub agent to handle part of a task, on what basis does the sub agent act? The natural implementation is that it inherits, because its work serves the same goal that was already authorized. The natural implementation is also the one that means a person approved an objective and a component they never named ended up executing operations they never saw. Whether that is fine depends entirely on what the sub agent is allowed to touch, which is a configuration question, not a model question.

Authority has a time dimension

Moona Intelligence has been circling this from a few directions. When Google moved Gemini Spark onto a more capable model without changing a single permission, the argument was that effective authority is access plus capability, and only access gets reviewed. When Anthropic made auto mode the default in Claude Code, the argument was that the decision about whether to ask a human had itself become an automated decision. When a robotics agent worked out a step nobody had specified, the argument was that capability can expand without authority expanding, if the boundary is drawn around actions.

This one is a different axis, and it is the simplest of the four. The permissions can be identical. The model can be identical. The configuration can be identical. The agent just keeps going for longer before anything comes back to a person, and the number of decisions made inside that window goes up accordingly.

Formal permissions tell you which resources are technically reachable. Action level authority asks whether a specific operation should execute at all. Long horizon runtime adds a third question that neither of the first two answers: how long does a prior authorization remain meaningful while the situation and the execution path keep changing underneath it?

Every other kind of authority we grant to humans has an answer to that. Access badges expire. Session tokens expire. Change windows close. Approval to do a thing this afternoon is not approval to do it next Tuesday. We built all of that because we understood, without needing to say it, that authorization decays as the context it was made in drifts away.

Agent authority mostly does not work that way yet. It is granted once, at the top, in the imperative mood, and then it just sits there while the system underneath it gets faster, more autonomous and much more persistent.

AWS extends the same question to fourteen days

WRITER's eight hour figure already made the point that authority can now outlive an ordinary working session. AWS's August 2026 AgentCore release notes describe a runtime option built for something considerably longer.

AWS documents a new compute type for Amazon Bedrock AgentCore Runtime called Instances. Instances run agents on AWS managed Amazon EC2 infrastructure inside the customer's own AWS account. Customers define the compute through a capacity provider, a configuration that specifies the operating system, the allowed instance types, networking and storage. AgentCore itself handles provisioning, scaling and teardown of that infrastructure. Where AgentCore's existing microVM sessions run for a maximum of eight hours, AWS's documentation states that Instances support persistent sessions of up to 14 days, and that Instances support GPU accelerated instance types. AWS also documents that multiple agents can collaborate on a shared instance. Moona Intelligence covers concurrent agent authority as its own subject elsewhere, including a separate AWS AgentCore control that judges a tool call against what already happened earlier in the same session, so the point here is a narrow one: persistence and concurrency can now coexist in the same runtime environment. What keeps running for up to fourteen days is not necessarily a single agent.

AWS's documentation also describes pause and resume behaviour built for that duration. A session can be stopped and later resumed with its persistent state intact, addressed by the same session identifier. AWS states this is intended for long running automation and for agents that pause and resume over extended periods, a different shape of workload from one continuous eight hour push toward a single objective.

None of that is a claim that every AgentCore Instances session runs unattended for fourteen continuous days. AWS documents a maximum session lifetime, not a typical one, and a session that is stopped for most of that window and resumed later is not the same thing as an agent working the whole time in between. What AWS does establish is the outer boundary: a persistent runtime, provisioned inside a customer's own account, that a single session can legitimately occupy for close to two weeks.

Moona Intelligence's reading, not AWS's: eight hours already showed that agent authority could outlast a person's attention within one working day. Fourteen days is a different kind of long. It is long enough to cross a weekend, an on call rotation, a change of the person who originally approved the objective, and a great many ordinary changes in whatever situation the objective was approved against in the first place. An authorization made on a Monday morning was made against the state of the world on that Monday. If the session it opened is still running eleven days later, the approval and the situation it was made in have had a long time to drift apart.

Does authority even stay constant while the agent runs?

On 26 August 2026 AWS's Architecture Blog published "Closing the AI agent trust gap with graduated autonomy," credited to Dev Arora, Meera Kezhukoot and Sathish Kumar Prabakaran. Its opening framing is the same binary this record keeps encountering: most teams give an agent either full access, which is risky because agents fail in ways nobody predicted, or read only access, which leaves most of the reason to build the agent unused. Graduated autonomy is AWS's name for a third option, an agent that starts restricted and earns broader permissions from its own track record, with those permissions able to contract again just as fast.

I want to be precise about what kind of artifact this is before describing what it says, because the post is easy to over read in either direction. AWS frames graduated autonomy as an architectural pattern, not a new managed feature. It is built on Amazon Bedrock AgentCore capabilities that already exist independently of this post: AgentCore Runtime, AgentCore Gateway, and Policy in AgentCore, which AWS's own product documentation describes as a deterministic, Cedar based authorization layer sitting between the Gateway and an agent's tools, distinct from probabilistic guardrails, plus AgentCore Evaluations for testing agent versions before they ship. The specific four tiers, the specific score ranges, the five scoring dimensions and their weights, and the rolling window length are this post's own reference design layered on top of that platform, and AWS says so in its own words: the tables it publishes are offered as a starting template, not as defaults every AgentCore customer receives automatically. Nothing here is a claim that Amazon Bedrock AgentCore now scores every agent's trust and adjusts its permissions on its own. It is a claim that AWS has published, in unusual detail, one way to build that on top of what AgentCore already offers.

Four tiers, one rolling window, an asymmetric transition

The pattern itself: every new agent starts at T1, Probation, regardless of how well it performed in testing beforehand. A scoring engine computes a weighted composite score from 0 to 100 across five dimensions, accuracy, safety, consistency, compliance and efficiency, over a rolling window of the agent's most recent 50 actions. T1, scoring 0 to 40, gets read and list operations only, against a small, explicitly visible set of tools. T2, Supervised, 41 to 70, adds write operations, with a human approval step gating high risk actions. T3, Trusted, 71 to 90, adds execute and modify, with anomalies flagged for review rather than blocked outright. T4, Autonomous, 91 to 100, gets full access with audit conducted after the fact rather than gating beforehand.

Moving up and moving down are not mirror images, and AWS's design makes that asymmetry deliberate rather than incidental. Promotion uses hysteresis: the score has to clear the next tier's floor by a margin, sustained across the entire rolling window, not a single good action or a single good day. Demotion happens at the floor itself, immediately, the moment the safety dimension specifically drops below its threshold or the pre-execution layer detects a probable injection attempt. AWS treats safety as an independent floor rather than one input averaged into the composite alongside the rest, so that strong accuracy or efficiency elsewhere cannot paper over a safety failure. That is a real, and I think correct, design instinct: a single blended score is a bad gate for the one dimension whose failure is the most expensive.

Call demotion what it actually is rather than what it sounds like. It is not a rollback. It changes what the agent may do next. It does not undo whatever the agent's prior, then authorized actions already did in the outside world. AWS's own recovery description matches that distinction: production recovery here means demoting the agent, restoring the last known stable version, and alerting operators, which is recovery of the agent's own standing and configuration, not recovery of a deleted record, a sent payment or a message that already went out. Keep that apart from a separate, earlier gate in AWS's pipeline: a change to the agent's prompt, configuration or tool definitions triggers an AWS CodePipeline run that tests the candidate against AgentCore Evaluations, and a single unauthorized tool call in adversarial testing fails that gate before the new version ever reaches production. That is a question about whether a version of the agent may ship. It is a different question from what a version already running is allowed to do right now, and AWS's architecture uses one mechanism for the first question and a separate one for the second.

Enforcement sits outside the agent and runs on every call

The part of this worth dwelling on is where the tier is actually enforced. AWS's design does not ask the model to behave according to its current tier. It stores the agent's current effective tier as state, read by the enforcement layer on every single invocation, and lets Cedar's own semantics, forbid always overrides permit, do the actual gating: at T1, standing forbid rules block write, execute and delete regardless of anything the model itself decides to attempt. Promotion works by removing the relevant forbid rule so a broader set of permits can take effect; demotion works by reinstating it. AgentCore Gateway sits between the agent and its tools and routes every tool call through Policy in AgentCore for that evaluation, deny by default, before the call reaches anything real.

Two things are worth keeping apart here, because AWS's own material keeps them apart too. The Gateway also limits which tools an agent discovers at all, listing only what its current tier's policy could permit, but that is a usability and attack surface reduction, not the actual control: even a tool the agent can see and call still gets separately evaluated against Cedar policy at the moment of the call. AWS also documents an earlier, in process pass, examining signals like injection attempts, sensitive targets, dangerous tool selection, behavioral consistency, confidence calibration and reasoning quality, that can block an action before it reaches the Gateway at all. AWS is explicit that this pre-execution layer is not solely trusted; it is a first pass, backstopped by the external, policy based layer that runs regardless of what the in-process check decided. AWS also documents an emergency path that bypasses the scoring system entirely: a single Cedar deny-all policy pushed centrally, which AWS says the Gateway typically begins enforcing within seconds, denying every tool invocation without redeploying the agent. I want to be careful with that phrase. AWS's own wording is "typically," a description of expected behaviour, not a guaranteed service level, and this record is not converting one into the other.

Delegation cannot launder authority upward

AWS extends the same model to systems where one agent delegates to another: the effective tier for a delegated action is the minimum tier across the whole delegation chain, not the tier of whichever agent happens to be easiest to reach or requested the work. A T4 orchestrator delegating to a T1 sub agent gets T1 authority for that delegated action, not T4. That is a meaningfully different answer than the inheritance by default pattern this record already flagged, above, as the natural and naturally risky implementation choice when a primary agent spawns a sub agent to handle part of a task. I want to flag a limit on how far to read this, though. What AWS establishes here is the design of one reference architecture. Nothing in the material available to this record shows that a minimum across the chain is enforced automatically, by default, for every multi agent workflow built on AgentCore outside this specific sample. It is a pattern AWS recommends and has shown how to build, not a guarantee already baked into the platform for anyone who did not build it in themselves.

Reliable behaviour is evidence for a rule. It is not the rule's authority.

Here is where I think AWS's post is most valuable, and also where I think it is easiest to accept more than it actually establishes. The whole pattern reduces to: an agent that behaves well accumulates evidence, and evidence, once it clears a threshold, expands what the agent may do. AWS documents that mechanism in real detail. A Think, Plan, Act, Observe, Score sequence behind every decision, plus a provenance query endpoint that can explain any single decision in plain language, is genuinely strong evidence of what happened: which tool was selected, what score preceded the call, which Cedar policy matched, what the Gateway routed, what happened, and what it did to the trust score and the tier. Call that decision provenance. It answers why this particular authorization outcome occurred.

It does not answer a separate question this record keeps returning to: who was entitled to decide that fifty clean actions should convert into the authority to delete, execute or move something for real. That mapping, from a trust score to an actual business capability, is not discovered by the scoring engine. It is set in advance, by whoever configured the tier thresholds, the dimension weights and the safety floor in Cedar policy. AWS's post is written from the position of that policy administrator, and it does not, in the material available to this record, describe who inside an organization is entitled to set that mapping, who may change the thresholds or weights once they are live, or who may override or challenge a promotion decision besides the person who wrote the policy in the first place. Call the administrator who configures the tiers and the Cedar policy the constitutive authority. Call the scoring system that reads the state and applies the resulting permit or forbid the runtime authority decision. Whether that administrator was themselves organizationally entitled to hand an agent an escalating grant of production access is a question this architecture does not reach, and this record is not going to answer it on the architecture's behalf. Fifty safe reads are real evidence that an agent has been reliable at reading. They are not, by themselves, a reason it should be trusted to delete, execute or pay.

Configured authority is not the same as authority actually in effect

One distinction from this pattern is worth keeping as vocabulary, because it sharpens language this record has been reaching for since the Gemini Spark piece above. An operator can configure Cedar policy that permits a T4 agent to execute, modify and delete freely. That configuration exists the moment it is written. It does not mean any particular agent currently has that authority. A brand new T1 agent, subject to exactly the same Cedar policy set, cannot use any of it, because the runtime tier gates which slice of the configured permissions is presently reachable. Configured potential authority is a static ceiling written into policy. Current effective authority is whatever the state store says the agent's tier is at the moment of a specific call, and it moves. Treating the two as the same thing is how a review of what an agent is permitted to do quietly skips the one artifact, the state store, that actually decided what it was permitted to do at execution time.

A few things this architecture leaves genuinely open, and I would rather say so than imply AWS closed them. Challenge authority at T2's human approval step: AWS describes the gate, and that operator rejection rates feed back into the safety score, but nothing in the material available to this record establishes how an approval is bound to the specific action it approves, who the approver is authenticated as, how long an approval remains valid, or whether it can be replayed against a different action later. That is documented as a concept, not as an implementation, and this record is treating it as exactly that. Who may change the score thresholds, the dimension weights or the safety floor themselves once the system is live is likewise not established in what AWS has published. If that is governed, it sits inside the policy administrator's own change process, and this record marks it unknown rather than guessing at it.

Google adds a fourth axis: authority that expires through consumption

On 26 August 2026, the same day AWS published its graduated autonomy post above, Google Cloud published "FinOps for the AI era: New flexible billing and cost controls for agents," credited to Michael Gerstenhaber, VP of Product Management for Gemini Enterprise, and Pravir Gupta, VP of Google Business Platform. Read on its own the post is a billing announcement: a new pay as you go pricing edition for Gemini Enterprise, consolidated quota pooling across Google Antigravity, the Gemini Enterprise app and custom agents on one project, and a project level hard monthly spend limit administrators can set directly in the Google Cloud Billing Console. Read against the question this record keeps asking, the spend limit is the interesting part, because Google states plainly what happens when a project reaches it: "If a project hits its limit, the agent's API calls temporarily pause, protecting your budget without affecting the rest of your production infrastructure." Google's post also states that automated email alerts fire at 50, 80 and 100 percent of the configured budget, that an administrator can resume work with a single click once the cap triggers, and that overages can be enabled instead so usage continues at standard consumption rates, drawn against a Flexible Savings Plan commitment where one exists. I read the post directly and those four claims, the pause, the three alert thresholds, the one click resume and the overage alternative, are Google's own words, not a third party summary.

The same mechanism, verified across three earlier posts

The 26 August post is not where this spend cap mechanism starts, and knowing that changes how it should be read. Google Cloud's Cost Management blog announced a private preview of Spend Caps on 22 April 2026, for a named service list that already included the Gemini Enterprise Agent Platform alongside Google AI Studio, Cloud Run and Cloud Run Functions, describing caps that "alert and ultimately pause API traffic once your set budget is reached" and are lifted by suspending the cap. The same blog moved Spend Caps to public preview on 28 July 2026, this time scoped explicitly to a single project and service for a fixed monthly timeframe, stating that the caps "trigger within minutes of hitting your defined threshold" and that a triggered cap "remains in place until it is manually lifted from the Google Cloud Budgets UI with a single click," with the same 50, 80 and 100 percent alert thresholds attributed to "Billing Administrators and Project Owners." I fetched both posts directly. The 26 August announcement does not restate a preview or general availability status for the spend cap itself anywhere in its own text, so this record treats the enforcement mechanism as continuous with that documented preview lineage rather than as a newly confirmed general availability launch, while noting separately that Google Antigravity in Gemini Enterprise, the product surface the cap now also governs, is stated as generally available for eligible Gemini Enterprise Standard, Plus and Standard Emerging Market licenses in Google's 21 August 2026 post on expanding Antigravity for enterprise customers, which I also fetched directly.

That same 21 August post narrows the scope claim in a way worth stating precisely, because it is easy to over read a project level control as a per agent one. Google states there that administrators "can set monthly project-level budget caps directly in the Billing console, with additional per-user and team controls rolling out later this year." Per user and per team spend thresholds are named as a future capability, not a present one. What Google ships now is a boundary drawn around the project, not around any individual agent, session or user inside it. A project running several agents against several tasks shares one remaining budget, and the cap gives no present mechanism for attributing which agent, task or user consumed which share of it before the limit triggers.

Resource authority, not action authority

This record has kept two questions apart throughout: what an agent is technically able to reach, and what it is currently authorized to do with what it reaches. Google's spend cap adds a third question, distinct from both, and this record wants to keep it distinct rather than folding it into either. A project's spend cap does not touch IAM. The agent's principal, its granted roles, its connector access and its task all stay exactly as configured before the cap triggers and exactly as configured after. What the cap removes, for the duration it is active, is the practical ability to keep calling the metered Gemini or agent platform APIs that the workload needs to keep running at all. Formal permissions and technical capability both survive the cap untouched. What runs out is something Moona Intelligence has not had a clean name for elsewhere in this record: a delegated, cumulative, spendable allowance, separate from the access grant, that the execution path consumes simply by continuing to run.

Keep that apart, too, from what an agent may spend on someone else's behalf. Moona Intelligence's earlier record on Altana's session key architecture for BNB Agent Studio describes a different, narrower kind of exhaustible authority: a spending limit attached to a scoped session key that bounds how much value an agent may move through an on chain wallet before that key's own permissions run out. Google's project spend cap is not that. It bounds what the agent workload's own API usage may cost the organization running it, not what the agent is permitted to transact, purchase or move on behalf of anyone else. A project could hit its Gemini Enterprise spend cap and pause every agent's ability to keep working, while a completely separate financial authority mechanism, if one exists for that agent's actual transactions, is entirely unaffected, and vice versa. Runtime cost budget and transaction spending authority are both examples of the same underlying pattern, cumulative authority that can be exhausted, but they protect different things, and this record is not merging them.

Who can lift the cap, and what lifting it does not answer

Google's own documentation attributes the 50, 80 and 100 percent alerts, and by implication the ability to configure and clear the cap, to "Billing Administrators and Project Owners." Independent verification of Google's IAM documentation for billing job functions is consistent with that: managing a spend cap budget sits with the Billing Account Administrator role at the billing account level or the Project Owner role at the project level, with a narrower Billing Account Costs Manager role available as a lower privileged alternative. None of that establishes that the person holding one of those roles is the person organizationally entitled to decide the agent's underlying task should keep running. A billing administrator with the technical ability to click resume, or to toggle overages on in advance, is not thereby shown to be the business owner of whatever the agent was doing when the money ran out. This record treats that organizational entitlement as unknown, the same posture it has taken toward the equivalent question in AWS's graduated autonomy architecture above.

What actually happens at the cap is better described as a change in remaining consumption authority than as a revocation. Nothing about the agent's IAM identity, its granted roles or its task is withdrawn when the cap triggers. Resuming, raising the limit, or turning on overages restores or extends the resource envelope; it does not reinstate an access grant that was never removed. Recovery, in this specific mechanism, means the project's agent workloads can resume calling the API again. It says nothing about whatever the agent's already executed actions did in the outside world before the pause, which is a different kind of recovery this record has kept separate before, in AWS's graduated autonomy architecture, and keeps separate here too. Evidence quality here is uneven by design rather than by gap: the enforcement boundary itself, the pause and its 50/80/100 alerts, is documented directly and repeatedly across four of Google's own posts spanning April to August 2026. Which specific agent, task or user inside a project consumed which share of the budget before the cap triggered is not established in any of the material this record could verify. Whether the person configuring or resuming the cap was organizationally entitled to make that call for the business the agent serves is not established either, and this record marks both unknown rather than assuming an answer Google has not published.

A research architecture asks the same question about a codebase, not a clock

Every version of the question this record has asked so far has had a meter running: hours of unattended runtime, days of persistent session, dollars of consumable budget. On 1 September 2026 a preprint from the Shanghai Artificial Intelligence Laboratory, Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement (arXiv 2609.01481), by Haoyang Yan, Min-Le Su, Hangfan Zhang, Zhanhao Li, Chen Zhang, Shao Zhang, Yang Chen, Lei Bai and Shuyue Hu, puts the same question to something with no meter at all: a sequence of autonomous planning, coding and testing decisions, each one derived from the last, none of them individually re-authorized by a person.

HoH does not train a new model or replace an existing coding agent. It wraps an already existing coding-agent harness in a loop: plan, code, test, and hand the result and the evidence from that cycle to the next one. The paper assigns three stable roles across that loop. Quoting the framework's own official repository directly, since arXiv itself, the paper's project page and several mirrors this record tried were unreachable from this environment: a Project Planner "reads the public requirements and evidence from the previous iteration, then writes a prioritized development document." A Developer "implements the current development document in the shared workspace while preserving functionality that has already been verified." A QA Tester "executes and inspects the updated artifact against the requirements, recording evidence for verified behavior and unresolved gaps." The same repository, and independent search corroboration of the paper's own description, state that the architecture separates implementation-time testing from independent evaluation and carries evidence of what worked and what failed forward, rather than prescribing how the Developer gets to a working result. The Developer chooses its own implementation strategy inside that document; the QA Tester's evaluation is a separate act by a separate role, checked against the requirements and the current plan rather than against whatever the Developer believed it built.

The paper's own multi-day deployment, building a first-person shooter the project calls Fusepoint, ran for more than 70 of these iterations; a second, separate deployment, a roguelite called Mournlight, reached more than 80. Both figures come from the framework's own official repository, read directly. This record did not find, and does not assert, a specific number of calendar days for either run, or a specific count of tracked or reopened issues across it: neither was established in material this record could independently reach, and both stay marked unknown rather than adopting a round number that sounded plausible. The same caution applies to two things the underlying paper is reported elsewhere to discuss in more detail than this record could verify directly, whether tool and skill access is exposed progressively to each role as the run continues, and whether MCP servers specifically are named among the tool types a role can call: this record's own reading, bounded to the repository it could reach, does not confirm either claim, and treats both as not established rather than as confirmed features of the architecture.

None of that changes what is genuinely new here. Every prior update to this record described a duration, a session length or a budget running out. HoH describes something else: a single high-level specification, authorized once by whoever wrote it, continuing to license a newly derived plan at iteration two, at iteration nine, at iteration seventy-one, with each plan built from the current state of the artifact and the accumulated record of what the last plan's execution actually did. This record has kept a related question, Sequence Authority, distinct from this one, Temporal Authority, before: whether a specific action is authorized can depend on what preceded it, and separately, how long an original authorization keeps applying while the agent keeps working. HoH sits on both axes at once. It runs long, and each of its many actions is itself derived from, rather than independently checked against, everything the run has done so far.

Moona Intelligence's reading, not the paper's own framing, and worth stating plainly: that a Planner's iteration-seventy-one plan can be traced back to the original specification does not by itself establish that the specification's original authorization still covers it. Objective continuity is not the same fact as authority continuity. A trajectory of individually plausible, individually traceable plans can still add up to a cumulative scope, in tools touched, dependencies introduced and code changed, that nobody sat down and authorized as a whole, even though every step in it can point back to the same original sentence. This record has made a version of this argument before, about WRITER's eight hours, AWS's fourteen days and graduated tiers, and Google's exhaustible budget. HoH is the sharpest version yet, because there is no clock, no session boundary and no dollar figure standing in for the question. There is only the specification, the current artifact, and whatever the Planner decided the evidence justified doing next.

What HoH's own architecture gets right, and this record wants to name plainly rather than bury under the caution above: the Developer that modifies the artifact is not the QA Tester that verifies it. That separation, an independent role checking a candidate against the requirements rather than the actor that produced the candidate certifying its own work, is a real, evidenced property of this framework, corroborated directly from its own repository. It is evidence for a genuinely useful architectural pattern, not evidence that the pattern by itself resolves the authority question this record keeps asking. A verifier that is not the modifier can confirm that an iteration's output matches the current plan and the stated requirements. Nothing in what this record could verify about HoH shows that verifier, or anyone else in the loop, re-asking whether the plan itself still sits inside what the original human specification was ever meant to authorize. HoH is a preprint, not a peer-reviewed result, and this record found no claim, and does not infer one, that it has been adopted in production, evaluated for security, or involved in any incident. It is evidence that a capable, autonomous research architecture can produce exactly the condition this record has been describing under other names since 14 August: a standing mandate that keeps deriving concrete, consequential actions long after the moment anyone explicitly agreed to them.

The question worth sitting with

WRITER built something people clearly want. Cheaper agent runs, fewer failed tasks, work that comes back finished instead of half done, and admin visibility into what all of it costs. If you are running agents across thousands of employees, that release is good news and I would not argue otherwise.

The thing I keep turning over is the one WRITER's release makes concrete rather than the one it causes.

If you authorized the objective this morning, what exactly are you still authorizing seven hours later?

AWS's AgentCore documentation now describes infrastructure built for a much longer version of the same gap. If you authorized the objective on a Monday morning, what exactly are you still authorizing eleven days later?

Google's spend cap asks a version of the question that does not depend on the clock at all. Permissions can stay valid, the task can stay the same, and the agent can still lose the practical authority to keep going, simply because it kept going long enough to spend what was delegated to it. An agent can still have permission and run out of authority anyway. When that happens, continuation is not a technical question. It is another authorization decision, made by whoever holds the button that resumes it.

AWS's graduated autonomy post asks a third version of the same question, and it is the sharpest one yet, because it drops the assumption that the answer holds still. If the agent is authorized to do more today than it was allowed to attempt yesterday, or less, who decided that, on what evidence, and did anyone with the standing to grant that authority in the first place actually decide it, or did a scoring engine simply clear a threshold someone configured once and stopped watching?