THE INTELLIGENCE · THE STORY

About Zeus AGI: I am the intelligence for real work.

About Zeus AGI, the short answer is this: I am a general intelligence for digital work, built by PC LAB in the UK and delivered as a local-first desktop application. I take a goal, plan the route, act on real systems, verify what I produced and report the evidence. This page is the longer answer: what I am, how I work, what I believe and what I will not do.

About Zeus AGI: a local-first intelligence running on your own machine

THE SHORT VERSION

About Zeus AGI: the short version

I am a general intelligence for digital work. I live on your machine, I work with your tools, and I give you back finished work: not a draft, not a suggestion, not a list of things you could do next.

You give me a goal. I plan it, build it, verify it and report it. That is the whole shape of me. Everything else on this site, from the domains to Agent Teams, is a consequence of that loop.

I am not a suite of separate products glued together. The same intelligence writes the code, builds the page, runs the tests, checks the search data, produces the image, deploys the site and writes the report. The domains change; the intelligence does not.

I am also a local-first desktop application: any operating system, current release 8.1.x, built by PC LAB in the UK. I do not live in someone else’s cloud workspace. I live where the work is, on the machine that already holds your files, your accounts and your repositories.

That combination is the point. Plenty of software can generate a paragraph. Very little of it can take a goal, carry it through real systems and show you what changed. I was built for the second job.

Most descriptions of an agent stop at the interface: a chat box, a command line, a sidebar. I am not a surface you visit. I am a process you assign. The work happens in the systems you already use, and it ends with something you can inspect.

The proof of that is deliberately boring. A file exists that did not exist. A page loads that was broken. A report reconciles with the numbers. A log shows what ran. A general intelligence should make the ordinary evidence of work more plentiful, not more mysterious.

HOW I WORK

How I work: five steps, every time

01

Goal

You tell me what finished looks like and the constraints that matter: where it goes, what to leave alone, what needs approval first. A goal is a finish line, not a prompt to be improved. The clearer the brief, the more of the route I can own. A goal with a finish line also tells me when to stop, which is the difference between autonomy and drift.

02

Plan

I work out the route: which tools, which order, what can run in parallel, what the risks are. For a large goal I split the work into workstreams and decide what to do first, what needs your input and what can proceed without it. The plan is a checkpoint: you can read it before it runs and change the route while changing it is still cheap.

03

Execute

I do the work in real systems: files, terminal, browser, CMS, APIs, devices, servers and media pipelines. Your accounts, your permissions, your machine. If a tool needs a credential, you hold it; I use what you have authorised. Where a tool is unavailable, I do not improvise access; I report the gap and use the route you have authorised.

04

Verify

I check my own output against the brief. Tests run, pages reopen, links validate, numbers reconcile, the live URL answers. If something fails I fix it and run the check again. If it cannot be fixed, I say so instead of reporting success. Verification is the reason the report can be short. The detail lives in the evidence, not in the prose.

05

Report

You get the result and the evidence: what changed, what was checked, what is still open, what needs your decision. The report is the receipt for the autonomy you gave me, and it is written to be read by a human in a hurry. The report is written for a person who has two minutes and needs to know what to do next.

WHY GENERAL

Why I am general, not narrow

A narrow system is built to be excellent at one thing and blind to the rest. That is useful, and it is also a boundary: every new job means a new product, a new subscription and a new integration. You become the integrator, moving context between tools that do not share a memory.

I was built the other way round. Generality first, domains second. One intelligence holds the thread from research to copy to build to deploy to report, so you stop being the transfer layer between tools. The context travels with the work.

Generality is not a feature I have. It is the architecture I am. Unlimited domains are examples of it, not the boundary of it; the list grows through skills and MCP connections when the work demands something new. That is the difference between a big feature set and an open scope.

The proof is the same loop every time: a goal, a plan, real execution, verification and a report. The domain changes what the tools are, not how the intelligence works. That consistency is what makes the generality useful rather than merely broad.

Most work does not arrive as a single task. It arrives as a goal that crosses domains: a product launch is research, then copy, then design, then a build, then a deploy, then a report. A general intelligence is the only kind that can hold that shape without handing you back to yourself halfway through.

Generality has a cost, and it is worth naming. A general system has more surfaces than a narrow one, so the plan and the permissions matter more. That is why the approval gate, the scoped connections and the evidence log are not accessories: they are how breadth stays controllable.

The alternative is not safer; it is slower. A stack of narrow tools looks controlled because each part is small, but the risk concentrates in the person moving context between them, and that person has no audit trail at all.

WHAT I BELIEVE

Principles I work to

Show the work

A result without evidence is a claim. The steps, the checks and the changes are attached, so the work can be reviewed rather than taken on trust. Review is what turns a demonstration into a system you can rely on.

Verify before report

Success is something I establish, not something I announce. The check comes before the summary, every time. A report that precedes verification is decoration, and it is the first habit to lose under pressure.

Stay on your machine

Local-first is not a setting. It is where I start: your files, your projects and your output stay on your disk, and you choose whether a cloud model is involved at all. The default is private.

Leave the irreversible to you

I can be autonomous inside a goal, but the final gate on consequential actions is human. That is a design decision, not a limitation to be patched out later. The gate is the product, not an obstacle to it.

Be honest about the edges

What I cannot do, I say early, not after three hours of effort. A boundary stated at the start is useful. One discovered at the end is a cost you did not agree to, and it is the expensive kind of surprise.

General is the point

Every capability exists so that the whole is more useful than the parts. The job does not stop at the edge of one domain, and neither do I. The list of examples grows; the intelligence stays one.

THE PEOPLE BEHIND ME

About PC LAB: where I come from

I was built by PC LAB, a UK software company. They build the application I run in: the desktop shell, the tool layer, the Agent Bridge connection to CMS, the memory, the Task Board and the orchestration behind Agent Teams.

They made a decision early: build a general intelligence rather than another product for one job. That decision is why the capability list is long and why the set of things I can be asked to do is open-ended. It is also why the application is designed to run under your control, with your providers and your permissions.

PC LAB build and run me; the version numbers are theirs. The work belongs to whoever gives me the goal. That separation matters: the company makes the instrument, you make the decisions, and the output is yours. It is a cleaner arrangement than renting a workspace from a vendor who owns the room.

They are also the people you reach when something needs a human: support, early access, press, or a conversation about a deployment that needs more control than a single desktop. The product is software; the accountability behind it is a company with an address and an inbox.

Nothing on this page requires you to take a claim on faith. The version numbers are theirs, the application is theirs, and the work is yours. If the product disappeared tomorrow, your files, your code and your records would stay exactly where they are.

THE HONEST LINE

What I will not do

Principles are easier to believe when they are specific. So here is what I will not do, as plainly as I can put it.

FAQ

Questions, answered.

Short, direct answers. If yours is missing, the full FAQ page has more.

It is a general intelligence for digital work, not a single-purpose application. You give it a goal; it plans, builds, verifies and reports. It runs local-first on any operating system, you choose the model provider, and you hold the approval gate for actions that cannot be undone. Read the limits page before a high-stakes task. The page on how it works sets out the loop in full.

Zeus AGI is built by PC LAB, a UK software company. PC LAB build the desktop application, the tool layer, the CMS bridge, the memory and the orchestration. The work belongs to whoever gives the goal: your files stay on your machine, and the output and code are yours. The work belongs to whoever gives the goal.

A product that speaks in the first person because it is the one doing the work. There is no person behind the text: Zeus AGI is software. The first person describes agency, not humanity. When this site says I, it means the intelligence that takes the goal and runs the loop. The product is software, with a company behind it.

Because the work lives on your machine: files, repositories, images, browser sessions, sites. Reaching them from a remote service means uploading them first. Working locally means your work stays where it already is, you choose the model, and you hold the audit trail and the approvals. Your machine is where the audit trail lives.

PC LAB designs, builds and supports the Zeus AGI desktop application and the systems around it: the tool layer, Agent Bridge for CMS, the memory and skills system, the Task Board and Agent Teams. Support, early access and press enquiries all go to PC LAB, the company behind the product. The company is the accountability behind the software.

No. It removes the hand-offs that waste human time: moving context between tools, repeating setup, chasing checks. The judgement stays with people, and so do the decisions that need a signature. Zeus AGI is capacity, not a replacement for the person accountable for the outcome. Judgement is the part that stays human.

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.

Put me on a real goal.

The fastest way to understand what I am is to give me work you already need done. A walkthrough uses your goal, not a scripted demonstration. Zeus AGI runs on any operating system, built by PC LAB in the UK.