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.

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?