How AGI agents work: the autonomy loop, step by step.

Most descriptions of agents describe a conversation: you type, it replies, you type again. That is a chat interface with tools attached. It is not autonomy, and it is not how work gets delivered. The unit of work here is a goal, and the shape of the work is a loop.

The loop has five stages and it runs end to end: goal, plan, execute, verify, report. Each stage has an input and an output you can inspect. If a stage can be skipped, what you have is a shortcut with better marketing, not an autonomous system.

The loop is also the answer to the trust question. You do not have to believe the agent was careful; you can look at what it planned, what it touched, what it checked and what changed. Evidence is produced as the work happens, not reconstructed afterwards to fit the outcome.

One more thing about the shape. The loop is general: it does not change when the domain changes. A website build, a data reconciliation, a server check and an event run all use the same five stages with different tools. That is what makes generality practical rather than a talking point.

The sections that follow explain each stage, the systems around the loop (tools, permissions, memory, skills, Agent Teams), and then a worked example that crosses three domains in a single goal.

The loop is not a metaphor for a to-do list. It is a control structure: each stage produces something the next stage consumes, and the run cannot move forward without the previous output. That is what stops an agent from jumping to a confident conclusion on the first plausible idea.

Most failures in agent work are failures of the loop rather than of the model. A plan that skipped verification, an execution that guessed at a credential, a report that smoothed over a failed check. The loop exists to make those failures visible early, when they are cheap to correct.

That is also why the loop is visible to you at every stage. You can read the plan before it runs, watch the execution, inspect the verification and audit the report. Autonomy here is not a black box that returns an answer; it is a process you can supervise at whatever level of detail you choose.

Tools are how the loop touches the world. The list is ordinary on purpose: file system, terminal, Git, browser, CMS, SSH and hosting, APIs, the media studio, documents, the Task Board and scheduling. Generality comes from combining them, not from one spectacular tool.

Permissions are layered. The agent runs on your machine, under your user account, with the tools and credentials you have connected. You can scope what it may touch: a project folder, a site, a repository, a set of hosts. Nothing reaches beyond what you have connected, which keeps the risk surface understandable.

The approval gate is for the irreversible: deploying to production, deleting data, sending something external, changing a live server, spending money, signing anything. Those actions pause for your sign-off. Everything reversible can run without interrupting you, which is what makes autonomy useful rather than theatrical.

The gate is not a single checkbox at the end. It is configurable per project and per action class, and the agent is expected to plan around it: put the reversible work first, assemble everything the approval needs, then ask once with the context attached.

An audit trail records the whole sequence: the plan, the tool calls, the files changed, the commands run, the checks and their results. It is the difference between an agent you supervise and an agent you can hand work to. It is also the raw material for the report.

The approval gate is not only a safety mechanism; it is a planning constraint. Knowing where the gates are lets the agent order the work so that irreversible steps come last, with everything they depend on already verified. That is why an experienced run looks calm: the risk was sequenced, not discovered.

Permissions work the same way. A scoped connection is a promise about reach, and the agent plans inside it. If the job cannot be done inside the permissions, the correct behaviour is to say so and ask for the specific extension, not to look for a way around.

The audit trail closes the loop between what you authorised and what happened. Without it, autonomy is a story. With it, autonomy is a record you can review, which is the only version worth granting.

Memory is what makes week two better than week one. Project memory holds context: the brief, the conventions, the decisions and the reasons behind them. It is inspectable and editable. There is no hidden personality in there, just the record of the work.

Skills are reusable procedures: how a particular site is built, how a report is shaped, how a deployment is checked. When a way of working proves itself, it is saved as a skill and reused, which is how the intelligence extends itself without waiting for a new release.

The Task Board is the shared state of the work: what is planned, running, blocked or complete. It is how a long job stays coherent across sessions, and how Agent Teams coordinates without losing track of who owns what.

Add MCP connections and the same loop can reach systems that were never in the original build. A connection is a new set of tools; a skill is a new procedure; the loop itself does not change. That is the architecture that makes the domain list grow while the behaviour stays predictable.

This continuity is the quiet part of autonomy. A tool forgets you between sessions, so every job restarts from zero. A system with memory and skills compounds: the second job starts where the first finished, and the third is faster again.

Continuity changes the cost of the second job. The first run pays the setup: the conventions, the decisions, the shape of the report. Later runs draw on it. A team that works this way accumulates context in the system rather than in someone’s head.

Memory is also a risk surface, and it is treated as one. You can read it, edit it and remove it. It is project state, not a personality, and it goes where the project goes.

Continuity also changes how a team hands work over. When a colleague leaves a project, the context does not leave with them. The memory, the board and the log are the handover, which is a quieter benefit than autonomy and often a more valuable one.

Autonomy is not a long answer, a bigger prompt or a model that sounds confident. It is the transfer of the route. If you still have to prompt each step, the autonomy is theatre, however fluent the output.

Autonomy is not unsupervised either. The gate on irreversible actions, the audit trail and the report are what make it safe to delegate. The agent moves fast inside the boundary and stops at the line. Speed inside a boundary is useful; speed without one is a liability.

And autonomy is not a promise that every job will succeed. A general intelligence will sometimes hit a system it cannot reach, a brief that contradicts itself or a task that needs a human signature. The loop closes with a report either way, and the report says which it was. An honest failure is a result; a dressed-up success is a risk.

That is the standard the loop is built to meet: every run either produces verified work or an accurate account of why it could not. Anything else is a demo.

Autonomy also has a social dimension. A colleague who delegates a goal needs to be able to explain what happened afterwards. The report and the evidence log exist so the person who delegated can stand behind the work, not just receive it.

The end of the loop is not the end of the work. Most real jobs produce a follow-on decision: publish or hold, extend or stop, repeat next month or retire. The report is written to make that decision easier, which is why it says what is still open rather than pretending the world is finished.

The test of a well-run loop is not that it never stops. It is that every stop has a reason a person can understand: an approval, a missing permission, a failed check, a brief that needs a decision. An unexplained stop is a bug in the autonomy.

That is why the report matters as much as the run.