A defined workspace
Give each agent the files, data, and actions its job requires. Keep everything else outside the boundary.
THE OPERATING MODEL
Give it a goal.
Keep it accountable.
A useful agent should observe, plan, act within its permissions, and review the outcome. Here is how we are designing that loop.
THE CONTINUOUS LOOP
The task ends.
The goal remains.
The next action should follow from the current state and the evidence. When the data is insufficient or the action is outside the allowed scope, the agent should ask or stop.
INTERACTIVE PRODUCT DEMO
SAMPLE DATAFrom signal to reviewed change.
Run a simulated content-refresh workflow. No website, account, or AI service is connected.
- 01Observe
- 02Plan
- 03Review
- 04Validate
ACTIVITY LOG
Ready. Start the example to see the workflow.
PROPOSED DIFF
/guides/agent-workflows
- A generic opening paragraph
+ A precise explanation of the workflow
+ An example with approval checkpoints
+ A link to the permissions guide
The scope excludes pricing, legal pages, credentials, and deployment settings.
Waiting to start
THE RULES OF THE LOOP
A system needs
more than a prompt.
A checkable output
The output needs to be a draft, a diff, a brief, or a report that someone can inspect.
A stop condition
Pause after repeated failures, uncertain facts, exhausted budgets, or missing approval.
COMMON QUESTIONS
Less mystery.
More control.
Will the agent publish without asking?
The proposed starting mode is review before publishing. Broader autonomy should only be enabled for explicitly allowed actions after the workflow is tested.
Is this the live product?
No. The page describes the operating model we are building. The interactive workflow uses sample data and does not call a model or change a website.
What happens when a check fails?
The workflow should stop, record the failure, and either try a bounded repair or ask for help. The exact retry and spending limits belong in its configuration.
Can I inspect what changed?
The planned Git-first workflow is designed to preserve a diff, a test result, an approval record, and a deploy revision. These are product requirements, not a claim that the backend is already built.
START SMALL. BUILD FROM THERE.
A useful first job.
Not a giant transformation.
Tell us what needs doing. We will start with a goal, a boundary, and a way to judge the result.