Surface — Standing agents
Standing responsibility, not a task.
Agents that wake on an event, do the work, and leave a proposal. Memory you can read and edit.
- Trigger
- An event
- Execution
- Assembled per trigger
- Review
- Reviewed hours to days later, out of band
- Gate
- Named human · queued
Definition
What it is
Agents that wake on an event — a ticket created, a build completed, a pipeline transition, a schedule — work on behalf of one person, and leave the result behind.
- They are not resident processes.
- They are durable memory, permissions, and credentials assembled when a trigger arrives and released when the run ends.
Approval
How approval works
Standing agents queue their approvals rather than bypass them.
- Awareness is broad; authority is none.
- Their memory is visible and editable by the person they work for, and every durable fact records where it came from.
Fit
When you reach for it
Watch this, and tell me when something matters. The case where the responsibility is standing and the trigger is not yours.
In practice
Three ways this gets used.
Engineering
Watch a requirements baseline for changes and flag the affected interface specifications and verification artifacts.
Program management
On ticket creation, check it against the work breakdown and propose linkage, estimate, and assignee — batched for a morning review.
Software development
On build failure, correlate against recent commits and prior similar failures, and return a candidate fix as a proposal.
Everywhere else
The same boundary, three other ways in.
Next
See Standing agents configured for your tools.
A briefing walks through how a handful of your real tools would register on this surface — the classes they reach, where the gates land, and what stays identical on the other three.