SCOPE · THE STATED BOUNDARY
What can an AGI agent do? Scope, limits and reach.
What can an AGI agent do? More than a feature list suggests, and less than a promise can claim. This page sets out the scope plainly: the work that is in, the work that is out, and how the boundary moves as skills and MCP connections are added. A scope you can inspect is worth more than a capability you have to assume.
IN SCOPE
What can an AGI agent do: the scope in full
The scope is general digital work, plus the device, system and machine-adjacent work that can be reached, supervised and approved. That is a wide description, so here it is broken down into the areas the product is built and tested for.
Outside those areas, the honest answer is not no forever. It is not yet, not reachable, or not without oversight, and the rest of this page explains which.
The list below is deliberately concrete. General statements about scope are easy to write and hard to test, so each line names work that can be checked: a site that can be deployed, a server that can be reached, a report that can be verified.
A scope list also protects the work. When the boundary is public, a conversation about a new task starts with what can be reached rather than a discovery halfway through the build. That saves the most expensive kind of time: the time spent finding out too late.
One more distinction: in scope does not mean automatic. Every line below still runs under permissions, approvals and the evidence model. Reach is what can be attempted; control is how it is attempted.
- Digital build: websites, pages, content, media, documents, data and code, from brief to deployment.
- Digital reach: CMS, SEO, browser sessions, forms, dashboards, APIs and hosting.
- Systems: servers, services and configurations over SSH and through hosting accounts.
- Devices: device-adjacent work within permissions, with the reachable boundary stated before work starts.
- Business areas: operations, records, reporting, quotes, reconciliations and the checks behind them.
- Events: planning, listings, comms, assets and follow-up, coordinated as one workstream.
- Medical and lab machines: supervised machine-adjacent workflows with approval at every consequential step and no clinical judgement.
- Invention: new products, prototypes, novel solutions and repairs to things that should not be broken.
- Orchestration: Agent Teams for work too large for a single thread, with one accountable report.
- Extension: new skills and MCP connections for systems that were not in the original build.
- Recorded work: the trail of what ran, what changed and what was checked, kept with the project.
- Records work: versions, approvals, documentation and the trail a reviewer will ask for.
- Integration work: connecting systems and keeping the flow between them honest.
OUT OF SCOPE
What is out of scope
The boundary is easier to trust when it is written down. Out of scope is not a marketing gap; it is where the honest answer is no, and where saying it early saves everyone the cost of finding out late.
- Physical work: building, moving or repairing hardware in the physical world. I can plan it, document it and coordinate it; I cannot turn a screwdriver.
- Signatures: legal, medical, financial or engineering decisions that require a qualified person. I can prepare the work around the decision; I cannot be the signature.
- Guarantees: outcomes that depend on third parties, markets, search rankings or regulation. I can do the work; I cannot promise the world's response.
- Unreachable systems: anything with no network path, no API, no MCP connection and no access you can grant.
- Unsupervised regulated work: clinical, laboratory or safety-critical actions without human oversight.
- Invented evidence: results, sources, benchmarks or proof I do not have. If I cannot show it, I will not claim it.
HOW THE BOUNDARY MOVES
Fixed scope and expanding scope
Scope is not a single number. It is the relationship between what you can describe, what can be reached and what can be approved, and it changes as each of those three grows.
A fixed product
- Scope is defined by the release.
- New domains need a new product.
- The boundary is a roadmap.
- You adapt your work to the tool.
- Scope grows when you buy the next product.
An extending intelligence
- Scope is defined by what can be described, reached and approved.
- New domains arrive through skills and MCP.
- The boundary is stated, not hidden.
- The tool adapts to the work.
- Scope grows when you connect the next system.
HOW IT EXPANDS
How scope expands with skills and MCP
The boundary is not static, and the mechanism is specific. A skill saves a procedure: a way of building, checking or reporting that proved itself and can be reused. An MCP connection adds a tool surface: a system the agent can act through. Both extend the scope without rebuilding the product.
The test is practical. If the work can be described and a system can be reached, the intelligence can usually be extended to it. If it cannot be reached, no amount of clever copy changes that. The direction of travel is one way: described work becomes reachable work, and reachable work becomes routine work.
Guardrails expand with scope. A new connection is a new permission, and permissions stay visible: what can be reached, what needs approval and what is out of bounds. Extension without governance would be a liability, not a feature. That is why the limits page sits next to this one rather than at the back of the site.
This is also why the list of examples keeps growing. The first release could only cover what was built into it. Every skill saved and every connection added widens the described work that can be delivered, and the loop that delivers it does not change.
Skills are the part that makes the extension durable. A one-off script solves one task; a skill solves a class of tasks. When the way of working proves itself, it is saved, and the next request in the same shape starts from a known-good procedure.
MCP is the part that makes the extension reachable. A system that was never in the original build can be added as a tool surface, scoped and approved like any other connection. The intelligence does not have to be rebuilt to do work it was not originally pointed at.
The practical test is not whether the extension is possible in theory but whether it is safe in this project. A new capability arrives with a new permission, a new set of actions and a new approval question. Extension and governance are the same conversation.
The direction matters for planning. A capability that is not connected today is not a permanent no; it is a prerequisite. That framing turns scope conversations into a list of decisions rather than a list of disappointments.
That is also the honest way to read the list below: a statement of what can be attempted today, with the mechanism for tomorrow stated next to it. A scope that could not move would be a product; a scope that moved without governance would be a risk.
SCOPE IN ORDINARY WORK
Where the scope lands in practice
Agencies
Client sites, SEO, content and media in parallel, with one accountable report per client. The scope travels from pitch asset to deployed page without a change of hand, and the evidence follows the work.
Ecommerce
Product pages, store maintenance, data reconciliation and seasonal work, with the checks behind each change recorded rather than assumed. Seasonal peaks get the same care as quiet weeks, because the loop does not know the calendar.
Local business
Listings, pages, reports, events and the maintenance nobody has time for. The routine work happens, and the owner sees what changed and why rather than chasing it through a tool.
Labs and operations
Supervised machine-adjacent work, records, reporting and the routines that keep a site running, with approvals at every consequential step. A qualified professional keeps the decisions.
HOW TO TEST IT
How to test the scope before you commit
01
Describe the work
Write the goal and the systems it touches in plain language. Naming the systems early is what turns a vague request into a scope question that can actually be answered.
02
Check reachability
The agent confirms what it can reach: files, sites, repositories, hosts, APIs, devices and machine-adjacent systems. Anything unreachable is named before the work starts.
03
Map the approvals
Consequential actions are listed with the gate they sit behind: production deployment, deletion, external send, server change, signature. You see the boundary of autonomy before you grant it.
04
Run one real task
A small real task produces a plan, an execution, a verification and an evidence log. The scope is then tested in practice rather than argued in theory.
05
Extend or refuse
If the work needs a system or permission that is not connected, the answer is an extension request or a clear refusal, not a workaround. The scope moves by decision, not by drift.
FAQ
Questions, answered.
Short, direct answers. If yours is missing, the full FAQ page has more.
With Zeus AGI, it can plan and deliver work across digital build, systems, devices, business operations, events, medical and lab machine workflows under supervision, and invention. The list is examples, not a limit: if the work can be described, reached through a computer and approved, it is in scope. The list is the start of the conversation. One real task settles it faster than a long description.
Physical work, signatures that need a qualified professional, guarantees of third-party outcomes, systems that cannot be reached and regulated actions without supervision. Invented evidence is out of scope too. The boundary is stated on this page because a scope you cannot inspect is a sales claim. The boundary is part of the product. If something is out of scope, the reason is stated with it. Each new capability brings its own permission with it.
Yes, through skills and MCP. A skill saves a proven procedure; an MCP connection adds a tool surface. Both extend what the intelligence can do without a new product release. Expansion also expands governance: a new permission, new approvals, still visible and still yours. Governance grows with capability. Expansion is a decision, not a default. The work and the evidence are the offer, not the outcome.
No. Scope is what the intelligence can attempt and verify, not what the world will reward. A site can be built and deployed, but ranking and sales depend on factors outside any agent’s control. The work and the evidence are in scope; the outcome is not promised. Scope is not a guarantee. The promise is the work and the proof of it. The professional’s decision is the one that counts.
Ask with the work attached. Describe the goal, the systems it touches and the approvals involved, and the answer will say what is reachable, what needs your decision and what is outside the line before the work starts. A walkthrough can test one real task. Bring the systems, not just the goal.
Supervised, machine-adjacent workflows are: records, checks, documentation, coordination and the routine work around the machine. Clinical judgement, diagnosis and unsupervised actions on patients are not. A human professional owns the decisions, and approvals sit at every consequential step, so the machine is never the last line of defence. Supervised work, qualified decisions.
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.
Test the scope with your own work.
Describe the goal and the systems it touches. The walkthrough will say what is reachable, what needs an approval and what is outside the line, before any work starts. Zeus AGI runs on any operating system, built by PC LAB in the UK.