I've been running agents around the clock for ten to fifteen days at a time, working through continuous, long-lasting sessions. Spending that much time inside this kind of environment has changed how I think about prompting.
At first, the question is how to get an agent to complete a task. But when agents keep working after the immediate exchange is over, a different question becomes more important: what keeps the system doing useful work when I'm no longer directing every step?
Keeping agents active is not the same as keeping them productive. A process can continue indefinitely without making meaningful progress. It can revisit decisions, generate unnecessary work, or produce changes that look complete until someone examines them.
The work, then, is not simply to extend the session. It is to build the conditions under which continued execution remains useful, coordinated, and accountable.
Increasingly, I'm not just prompting an agent. I'm shaping the architecture within which agents work.
The instruction extends beyond the prompt
In a direct interaction, much of the coordination happens through me. I decide what matters, provide context, inspect the result, identify the next task, and intervene when something goes wrong. The agent executes, but I supply much of the continuity.
In a persistent environment, some of those responsibilities need an explicit home.
The system needs ways to recognize relevant events, select appropriate work, preserve decisions, coordinate ownership, evaluate results, and determine when to stop or ask for help. A well-written task prompt does not resolve all of that.
This is where prompting begins to change character. Instead of only describing a desired output, I'm defining operating behavior: what an agent should pay attention to, what it is authorized to act on, what qualifies as productive work, what evidence it must produce, and what should happen when it encounters uncertainty.
But this does not mean the architecture is made of prompts. Instructions can describe a policy; the surrounding software still has to support and enforce it. Ownership, permissions, durable state, resource limits, and review requirements cannot depend entirely on an agent remembering to respect them.
The prompt expresses the intended behavior. The architecture makes that behavior possible, observable, and bounded.
Reactivity and initiative need different mechanisms
One part of my setup is reactive. Monitoring tools allow an agent environment to respond when something relevant changes. A ticket appears, a task becomes ready, or another environment produces something that requires attention.
This means I don't have to personally deliver every next instruction. Work can arrive through the system.
The other part is proactive. Through recurring loops and a prompt that encourages looking for productive tasks, agents can reassess their environment and identify useful work without waiting for a new message from me.
These are different responsibilities. Reactivity asks, "Something changed. Does it require a response?" Initiative asks, "Given the current objective and state of the work, is there something useful I should do?"
The difficulty is defining useful. "Always find something to do" is a poor operating policy. It can turn spare capacity into unnecessary changes, speculative improvements, or more tickets for other agents to process.
A better policy connects initiative to an existing objective, available evidence, explicit authority, and a reasonable cost. Sometimes the right action is to implement something. Sometimes it is to investigate a blocker, challenge an assumption, or request a decision. Sometimes there is no justified action, and the agent should return to monitoring.
The objective is not uninterrupted activity. It is sustained progress without requiring uninterrupted human direction.
Tickets are becoming coordination objects
I'm using a ticketing system with tags, connected to monitoring so that different agent environments can react in specialized ways.
In this setup, a tag is more than a label for a human scanning a board. It can become a routing signal. A ticket can make work discoverable to the appropriate environment, trigger a specialized response, or support spawning several agents to contribute to a larger objective.
That changes what a ticket represents. It is not just a reminder that something should happen. It becomes a shared object through which environments coordinate what needs to happen, who is responsible, and what state the work has reached.
Consider a change that affects both an interface and its underlying behavior. One environment could handle implementation, another could examine the interaction, and another could test whether the result satisfies the original requirement. Their contributions could be represented by related tickets, with explicit dependencies and a shared definition of completion.
The collaboration does not require every agent to inhabit the same conversation. It requires them to work against compatible state.
That distinction matters. Several agents working at once are not necessarily collaborating. Without clear ownership and handoffs, parallelism can produce duplicate effort, conflicting changes, or reviews of an outdated artifact.
The architecture has to make it possible to distinguish work that is available from work that is claimed, and a proposed result from an accepted one. Prompts help agents interpret those distinctions. The coordination system needs to preserve them.
Activity needs evidence
As these environments become more persistent, instrumentation and quality review become more important.
I'm incorporating an agent accountability ledger because a stream of activity is not enough to understand whether the system is fulfilling its responsibilities.
A transcript tells me what an agent said. A log tells me that something happened. The accountability question is different: what did the agent commit to, what did it actually produce, and what supports the claim that the work is complete?
The Ledger should connect a Commitment to its execution history and supporting evidence. That evidence might include an artifact, a code change, a test result, or a review tied to the version being evaluated. The record should also preserve unresolved objections rather than allowing a confident completion message to erase them.
This is also why I'm moving development and review in a more adversarial direction.
I don't mean giving agents argumentative personalities. I mean structuring review so that its job is to challenge the proposed result: identify unsupported assumptions, look for counterexamples, test failure conditions, and check whether the evidence actually supports acceptance.
Another agent agreeing with the first is not, by itself, sufficient verification. They could be repeating the same assumption. The useful question is not whether the review sounds reassuring, but whether it introduced a meaningful test that the work could have failed.
Instrumentation should support that distinction. I care less about the number of actions performed than about accepted results, reopened work, repeated failures, unresolved dependencies, and the resources consumed to reach a verified outcome.
Accountability turns "the agent is working" into a claim I can examine.
The terminal shows execution, but not the whole operation
This is where the interface starts to become inadequate.
The terminal remains useful for inspecting a process, reading output, debugging execution, and intervening directly. But once several environments are reacting to tickets, selecting work, producing artifacts, and reviewing one another, the important state is distributed across all of them.
I don't just need to see what each agent is saying. I need to understand what the system is doing together.
An agent can be producing constant output while making no accepted progress. Another can be quiet because it is correctly waiting for a dependency. A third can report completion while an unresolved review still prevents acceptance.
Those situations should look different in the interface without requiring me to reconstruct them from several transcripts.
The primary object in this interface should be the work, not the conversation.
I want to start with an objective and see its active Commitments, the environments responsible for them, the dependencies between them, and the evidence supporting their current state. From there, I should be able to inspect a specific run, artifact, review, or terminal session.
The interface also needs to expose relationships that a terminal does not naturally aggregate: what triggered an agent's activity, why it claimed a ticket, which version another agent reviewed, where work is blocked, and whether resource consumption is producing accepted results or repeated attempts.
Not every data point belongs on the main screen. The purpose is not to surround the operator with more telemetry. It is to make the consequential distinctions visible: progressing or cycling, waiting or abandoned, claimed or verified, autonomous or awaiting a decision.
And this cannot be read-only. I need to redirect priorities, pause an environment, adjust its authority, resolve conflicting ownership, or require additional review. Those interventions should become part of the shared operational record, rather than remaining isolated instructions in whichever terminal I happened to open.
The terminal remains an execution surface. It stops being the complete operating interface.
From directing each step to shaping how work continues
What these long-running sessions have clarified for me is that the important continuity is not simply the length of a conversation. It is whether the objective, work state, responsibilities, and evidence remain coherent as execution continues.
Prompting still matters. But its role expands from asking for an output to expressing policies for attention, initiative, collaboration, verification, and escalation.
The tickets make work addressable. The monitors make changes actionable. The loops make initiative possible. The Ledger and reviews make completion inspectable. The interface needs to bring those relationships into a form a person can understand and direct.
That is what I mean by prompting the architecture: moving from telling an agent what to do next toward defining how a system of agents determines, coordinates, and verifies what happens next.
The next interface I need is more than a better place to talk to agents. It is a place to understand and direct the work they are doing together.