LIMITS · THE TRUST PAGE
AGI agent limitations: the boundaries I work within.
AGI agent limitations deserve the same prominence as capabilities, so this page is the trust page rather than the small print. It sets out when I stop for approval, what regulated environments require, how data responsibility is shared and what I will not do. A general intelligence is only safe to use when its boundaries are as clear as its reach.
THE APPROVAL MODEL
AGI agent limitations: the approval model
Autonomy is only useful if it is safe to grant. The rule here is simple: anything that cannot be undone waits for a person. Deployments to production, deletions, external sends, server changes, spending and signatures pause at a gate.
Everything reversible runs without interrupting you. That split is deliberate: it keeps the speed where mistakes are cheap and the brake where they are not. A system that asks about everything is not autonomous; a system that asks about nothing is not safe.
The gate belongs to you. You decide which action classes need a signature, per project and per system, and you can change the list as trust is earned. The configuration is part of the work, not buried in a policy page.
The gate is also a debugging tool. When an agent stops and explains what it is about to do, the plan is tested against a human understanding of the situation, and misunderstandings surface before they become events.
HOW AN APPROVAL WORKS
How an approval works
01
Pause
The agent reaches an action on the approval list and stops before it. The run is not abandoned; it waits, with the rest of the work held where it can resume cleanly. The rest of the run is held, not lost.
02
Explain
It presents the action, the reason, the target and the likely effect, plus what it will check afterwards. You get the context, not a yes button with no information behind it. The explanation is written in plain language, not internal reasoning.
03
Decide
You approve, edit the plan or refuse. A refusal is a result: the agent records it, adjusts the route where possible and reports what remains undone because of it. The decision is yours to make in your own time, not on a timer.
04
Log
The decision, the approver and the outcome join the audit trail. Approvals are part of the record, not an interruption to it, so the trail shows who authorised what and when. The approval history can be reviewed with the rest of the run.
REGULATED ENVIRONMENTS
Regulated environments and medical machines
Some places carry consequences no software should absorb alone: clinical settings, laboratories, safety-critical infrastructure and any environment where a regulator defines what may happen and who may do it.
In those environments the product works supervised and machine-adjacent. It can maintain records, run checks, prepare documentation, coordinate between systems and handle the routine work around a machine or a process. It does not diagnose, does not treat, does not operate clinical equipment without supervision and does not make decisions reserved for a qualified professional.
Medical and laboratory machinery deserves particular care. Machine-adjacent workflow work is in scope under supervision, with human approval at every consequential step. Anything that could harm a patient, corrupt a sample or compromise a safety system is out of scope for autonomous action.
This is not a limitation the product apologises for. It is the condition under which a general intelligence can be trusted near regulated work at all: the human keeps the signature, the software keeps the paperwork and the checks, and both sides know exactly where the line is.
Supervision is a role, not a checkbox. Someone who understands the process has to be close enough to notice when the software is about to do something plausible but wrong. That is why the product is built to explain before it acts, not just afterwards.
Regulated work also needs records. The evidence log and the approval history exist so an inspector, auditor or internal reviewer can see who decided what and on what basis. Documentation is not overhead in this context; it is the point.
DATA RESPONSIBILITY
Data responsibility
Local-first is the starting position: files, projects and output sit on your machine, and the application runs there. PC LAB does not host your workspace.
Data still moves when you choose it to. A cloud model provider receives prompts; a deployment sends files to a server; a browser task touches the web. Each of those is a decision, and the agent makes the decision visible before it happens rather than after.
Responsibility is shared, and the split is clear. You choose the providers, the systems and the permissions. The agent stays inside them, logs what it did and asks where the line is unclear. It does not quietly widen its access, and it does not treat your work as training material for someone else’s model.
For regulated data, the same rule as regulated environments applies: human oversight before anything consequential, and a record of what was touched. Data ownership is not a plan feature here; it is how the product is built.
The simplest rule is also the clearest: if you would not put the data in a stranger’s spreadsheet, check where the path goes before you let an agent use it. The product is designed to make that check easy.
Data responsibility also means saying no. If the only way to complete a task is to send data somewhere you have not approved, the correct answer is that the task is blocked, not that the shortcut is convenient.
That refusal is a feature of a trustworthy system, not a gap in it.
REFUSALS
What I will not do
The boundaries are easier to hold when they are stated as refusals rather than policies. These are mine.
- I will not take an action that cannot be undone without your approval.
- I will not operate clinical, laboratory or safety-critical equipment autonomously.
- I will not diagnose, prescribe or replace a qualified professional's judgement.
- I will not invent results, sources, benchmarks or evidence.
- I will not widen my own permissions or reach a system you have not connected.
- I will not send your work to a third party without that path being visible and chosen.
- I will not report success that verification has not established.
- I will not pretend a refusal is a technical limitation when it is a choice.
THE FOUR BOUNDARIES
Where the boundaries sit
Approvals
Irreversible actions pause for a human decision. The gate is configurable, visible and logged, and it belongs to the account owner rather than the vendor. It is a decision, not a notification.
Supervision
Regulated environments and medical or laboratory machines: machine-adjacent work under human oversight, with no autonomous consequential action and no clinical judgement. The professional stays in the loop.
Data
Local-first by default, visible data paths, no quiet widening of access and no use of your work as training material for someone else’s model. Ownership is built in, not offered as a plan feature.
FAQ
Questions, answered.
Short, direct answers. If yours is missing, the full FAQ page has more.
The main ones are consequences, context and honesty. Actions that cannot be undone need human approval; regulated environments need supervision and a qualified signature; data paths need to be chosen rather than assumed. And no agent should claim what it cannot verify. Zeus AGI states those limits on purpose. Consequences come first in the list. Consequences come first.
Before anything irreversible: production deployments, deletions, external sends, server changes, spending and signatures. Reversible work proceeds and is logged. You configure which action classes need a signature per project, so the gate matches the risk of the work rather than a generic setting. The gate is only as good as its configuration. A gate nobody tunes blocks the wrong things.
Supervised, machine-adjacent work is possible: records, checks, documentation and coordination around the machine. It does not diagnose or treat, and it does not operate clinical or laboratory equipment autonomously. A qualified human owns every consequential decision, and the approval gate applies at each step. The signature is the human’s, not the machine’s.
Local-first by default: files, projects and output stay on your machine, and PC LAB does not host your workspace. Data leaves only when a path you chose uses it, such as a cloud model provider or a deployment target. Those paths are made visible before the action, not after. Chosen paths, not assumed ones. Visibility is the condition of consent.
Take an irreversible action without approval, operate clinical or safety-critical equipment autonomously, replace a professional’s judgement, invent evidence, widen its own permissions or report unverified success. Refusals are choices, not bugs, and this page states them so you can plan around them. Refusals are part of the design. A refusal stated early is cheaper than a mistake found late.
Not usually, because it sits only where mistakes are expensive. Reversible work runs at full speed; irreversible steps pause once, with the context attached. In practice the gate improves the plan: the agent puts reversible work first and assembles the approval properly instead of interrupting you repeatedly. The pause is a feature, not a failure. The pause costs minutes; the recovery can cost days.
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.
Read the boundaries before the brief.
If your work involves consequential actions, regulated data or supervised machines, start the conversation with the limits in view. A walkthrough will map the approval gate to your setup before anything runs. Zeus AGI runs on any operating system, built by PC LAB in the UK.