TECHNOLOGY · UNDER THE BONNET
AGI technology and architecture, explained in plain English.
AGI technology and architecture is usually described as a stack of mysterious parts; here it is described as a working system you could sketch on one page. A loop does the work, a tool layer connects it to real systems, an extension layer lets it grow, a state layer remembers and a control layer keeps it inside your permissions. The model is one component, not the whole intelligence.
THE WHOLE PICTURE
AGI technology and architecture: the parts
The architecture is easier to understand if you stop thinking about models for a moment. A model is one component; the intelligence is the system around it. That system has a loop, a tool layer, an extension layer, a state layer and a control layer.
The loop does the work. The tool layer connects it to real systems. The extension layer lets it grow. The state layer remembers and produces evidence. The control layer keeps it inside your permissions and your approvals. Remove any of those and you have something simpler but less useful.
None of it needs to be mysterious. This page describes each part in plain English, in roughly the order the work touches them.
The architecture also explains a behaviour you can see in the product. When a domain changes, the plan changes but the shape stays. That is not a coincidence of design taste; it is the loop being the stable part and the tools being the variable part.
Because of that, adding a domain is not a rewrite. It is a new set of tool calls, a new skill if the procedure is reusable and the same report at the end. The architecture is what makes an open scope affordable to maintain.
This page is not a specification. It is the mental model you need to predict how the product will behave: where it will be fast, where it will stop, what it will record and what you will still have to decide. A user who understands the loop can supervise it with far less effort.
- Agent loop: the five stages from goal to report.
- Tool layer: files, terminal, Git, browser, CMS, SSH, APIs, media, documents and scheduling.
- Extension layer: skills for procedures, MCP for tool surfaces.
- State layer: project memory, the Task Board and the evidence log.
- Control layer: permissions, approvals and the audit trail.
- Model layer: your choice of provider, including a local model.
THE AGENT LOOP
The agent loop, in plain English
01
Intake and plan
The goal and constraints are turned into a plan: tasks, tools, order, parallel branches and checkpoints. The plan is explicit rather than implied, because an explicit plan can be reviewed before anything irreversible happens. The plan is also where the budget lives: time, tokens, approvals and what to do if a step fails twice.
02
Tool dispatch
Each step is matched to a tool call with a bounded input. The tool layer is the only way the loop reaches the world: files, terminal, browser, CMS, SSH, APIs, media and scheduling. No tool, no action. Bounded inputs are what make a tool call auditable. A call with a clear input can be checked, repeated and explained.
03
Execution
Tool calls run under your permissions and are recorded as they happen. Failures at this layer are normal and expected: a command returns an error, a page does not load, a credential expires. The loop handles them as information, not as a reason to guess. The layer also owns the boundary: a tool outside the granted permissions does not run, whatever the plan says.
04
Verification harness
The result is checked against the brief: tests, page loads, link checks, reconciliations, live URL responses. Verification is a stage, not a sentiment. A run cannot proceed to report without it. A verification harness is code, not an intention, which is why the checks are consistent across runs.
05
Report and evidence
The run closes with a human-readable report and a machine-readable evidence log: plan, tool calls, changes, checks. The two are kept together so a claim can always be traced back to the thing that supports it. The report is written for a human and the log for a reviewer; both are produced by the same run.
THE EXTENSION LAYER
Tools, skills and MCP
Tools
The bounded actions the loop can take: file system, terminal, Git, browser, CMS through Agent Bridge, SSH and hosting, APIs, the media studio, documents and scheduling. Ordinary tools, combined with judgement. They are deliberately ordinary, because reliability matters more than novelty at this layer.
Skills
Reusable procedures saved when a way of working proves itself. A skill packages how a particular kind of site is built, report shaped or deployment checked, so the intelligence improves with use rather than starting cold. A skill is visible and editable, so the intelligence’s habits stay inspectable.
MCP
A protocol for adding tool surfaces. An MCP connection lets the agent act through a new system without the core product being rebuilt, which is how the scope extends beyond the original list. The connection is scoped like any other permission, with its own approvals.
THE STATE LAYER
Memory, Task Board and evidence log
Three pieces of state make the loop feel like continuity rather than a sequence of one-off tasks.
Project memory is stored with the project, not in a global profile. That distinction matters when you work across clients or products: the conventions of one project do not leak into another, and the context that belongs to a piece of work stays attached to it.
The Task Board is the human-readable version of the state. It answers the question a colleague would ask: what is being done, what is waiting, what is stuck. That is how a long run stays explainable to someone who was not watching it.
The evidence log is the audit layer. It is not written by the agent’s prose; it is written by the tool calls and checks themselves, which is the difference between a record and a narrative.
The state is the part of the product you own most directly.
- Project memory: the brief, conventions, decisions and the reasons behind them. Inspectable and editable, with no hidden personality in it.
- Task Board: what is planned, running, blocked and complete. The shared state that keeps a long job coherent across sessions and lets Agent Teams coordinate.
- Evidence log: plan, tool calls, files changed, commands run, checks and results. The record that makes a report auditable.
THE MODEL LAYER
Model choice: the engine is not the intelligence
Zeus AGI works with multiple model providers, and you choose. A cloud provider gives you capability per token and scale; a local model keeps inference on your own hardware. Changing provider changes the engine, not the job.
The separation matters. The intelligence is in how the system plans, acts, verifies and remembers, not in one model’s weights. That is why the product can offer provider choice without becoming a different product each time, and why a model upgrade improves the engine rather than redefining the tool.
It also changes the economics and the privacy story. A local model can keep an entire task on your machine when the work demands it; a cloud provider can be used when the capability is worth the network path. The decision is yours, and the loop is indifferent.
That indifference is the architectural point. A system whose identity depends on one vendor’s model is a wrapper. A system whose identity is the loop, the tools and the evidence is a product that can outlast any single model.
Provider choice is also a risk decision, not only a cost decision. An organisation may require a specific provider, a specific region or no external provider at all. The model layer makes that a configuration rather than an argument about architecture.
The loop is designed to survive a change of engine. If a provider is unavailable, the run can be retried on another; if a local model is the requirement, the system can run entirely on the machine. Portability is a property of the architecture.
A model change should be an operational decision, not an identity crisis, and the architecture is built to keep it that way.
THE LOCAL CHOICE
Why local-first is architecture, not a setting
Local-first is not a preference switched on in a menu. The application runs on your machine, the state is stored there, and the tool layer acts on your files and accounts. The default is that nothing leaves your machine unless the work needs a network path.
That design follows from where the work is. Your repositories, images, browser sessions and sites are local or reachable from local. Reaching them from a remote service means uploading them first; working locally means the intelligence goes to the work rather than the work travelling to the intelligence.
It also changes what the product can be trusted with. Approvals, the audit trail and the memory sit on your machine, where you can inspect them. A local-first agent is not a service you rent; it is software you run, and the architecture is what makes that real rather than a slogan.
The result is software that behaves like an agent and is maintained like software: versioned, documented, inspectable and yours. That combination is rarer than either half on its own.
FAQ
Questions, answered.
Short, direct answers. If yours is missing, the full FAQ page has more.
A system built around a model rather than a model alone: an agent loop, a tool layer, an extension layer for skills and MCP, a state layer for memory and evidence, a control layer for permissions and approvals, and a model layer you choose. The intelligence is in the system’s behaviour, not in one model.
Goal and constraints become an explicit plan; each step is dispatched to a bounded tool call; execution runs under your permissions and is logged; verification checks the result against the brief; the run closes with a report and an evidence log. The loop cannot skip verification.
Skills are reusable procedures saved when a way of working proves itself. MCP is a protocol for adding tool surfaces, so the agent can act through a new system without the core product being rebuilt. Together they are how scope grows while the loop stays the same.
The run’s record: the plan, tool calls, files changed, commands run, checks and their results. It is produced as the work happens and kept with the report, so any claim in the summary can be traced to the thing that supports it.
You choose. Zeus AGI supports multiple model providers, and you can run a local model on your own hardware for private work. The system’s planning, tool use, verification and memory are what make it a general intelligence; the model is the engine, not the product.
Because the work lives on your machine. Local-first keeps state, files and evidence where the work is, avoids uploading your projects to act on them, and puts the audit trail where you can inspect it. Network calls happen when you choose them, not by default.
BEYOND THIS
This is one example. The next domain is a request away.
Zeus AGI acquires the skills it needs and connects MCP servers, so the scope is not a fixed feature list. If the work is digital or device based, it is in scope.
Look under the bonnet.
A walkthrough can show the loop, the tool layer and the evidence log on a task from your own work, so the architecture is concrete rather than a diagram. Zeus AGI runs local-first on any operating system, built by PC LAB in the UK.