UCA vs. AGI: A Practical Way to Think About AI Automation

Most conversations about the future of AI eventually reach the same question: when will we have Artificial General Intelligence?

AGI usually means a system that can perform a wide range of intellectual tasks at or above a human level. Researchers still disagree on the exact definition, but the conversation tends to focus on the capability of the machine. How broadly can it reason, learn, plan, and act?

That question matters, but I find a different question more useful when I am building real systems:

Which tasks become automatable when a computer can both do the work and check the result?

I call that idea Universal Computable Automation (UCA).

AGI is about the general capability of a machine. UCA is about the structure of a task.

The UCA idea

By "computable evaluation," I mean a check that software can run.

A test suite can check whether code still works. A spreadsheet can check whether two totals reconcile. A schema can check whether data has the right shape. A performance budget can check whether a page loads within a target.

When a system can perform a task, inspect the result, and try again, execution becomes much easier to automate. The AI does not need to get everything right on its first attempt. It needs a useful way to tell whether the attempt worked.

The word "universal" does not mean every human activity is automatable. It refers only to tasks that fit the definition: a machine can perform or direct the work, and software can evaluate the result.

UCA is also a horizon, not a claim that we have reached it. Many tasks that look computable are still difficult, expensive, or unsafe to automate today.

The idea borrows from the boundary Alan Turing formalized in On Computable Numbers, but UCA is not a mathematical theorem. It is my way of applying the idea of computability to automation.

Evaluation changes execution

AI agents are much more useful when success is visible.

Consider a code change. If the repository has tests, type checks, screenshots, and a clear description of the expected behavior, an agent can make a change and check its own work. If the request is only "make the product better," the model has no reliable way to know whether it succeeded.

The same pattern appears outside software:

• A system can reconcile financial records when the source data and balancing rules are clear. It cannot decide on its own which financial tradeoffs a company should accept.
• A system can migrate thousands of documents when the output format is defined. It cannot decide whether the new information structure makes sense for every future reader.
• A system can generate and test many campaign variants. It cannot decide what a brand should stand for.

The clearer the evaluation, the more of the execution loop a system can handle. The harder it is to define "good," the more human judgment remains part of the work.

How UCA differs from AGI

AGI and UCA describe different things:

	AGI	UCA
Focus	The capability of the system	The structure of the task
Main concern	Breadth and level of intelligence	Whether execution and evaluation can be automated
Evidence	Performance across many kinds of work	A working loop that can act, check, and improve
Practical use	Comparing progress toward general intelligence	Deciding what work can be automated now

One useful AGI framework from Google DeepMind separates performance, generality, and autonomy. UCA does not replace that kind of research. It answers a different question.

We could automate a large amount of work without settling whether a machine understands the world in a human way. Current systems are uneven, but they can still do meaningful work when they have the right tools, context, and checks.

The reverse is also true. A more generally capable system would not make every goal clear or every tradeoff objective. Intelligence does not remove the need to decide what should happen.

Judgment is part of the system

Most valuable work includes choices that cannot be reduced to a single test.

Someone still has to choose the goal, define the constraints, decide which risks are acceptable, and judge whether the result is actually useful. An AI can help with those decisions, but helping is not the same as owning the decision.

This is the pattern I keep seeing in my work on Friday. Agents perform best when the environment makes success legible. The hard part often moves away from producing the output and toward defining the work well enough that the output can be trusted.

That makes specification and evaluation part of the real work. They are not paperwork around the work.

The limits of evaluation

A computable check can still be wrong.

Tests can miss an important bug. A report can match its schema and still tell the wrong story. A metric can encourage behavior that improves the number while making the actual product worse.

This matters because UCA is only as good as the evaluation around it. If the check captures the wrong thing, the system can become very efficient at producing the wrong result.

Some tasks also have goals that change as the work unfolds. Strategy, care, taste, leadership, and ethics involve people who may disagree about what success means. Parts of those tasks can be automated, but the whole task may not have one stable answer.

And even when a result can be checked, the action may still require human approval. Sending money, publishing a statement, deleting data, or making a decision that affects another person should not become automatic merely because the software can verify part of the process.

The part I cannot prove

The original version of this essay argued that human judgment is non-computable. I stated that too confidently.

I do not know how to prove that human judgment sits outside computation. Models may learn more of what currently feels like judgment. Evaluations may also become more capable, including models that evaluate the work of other models.

Hubert Dreyfus argued that human expertise is embodied and situated, not simply a collection of explicit rules. His critique is still useful, even if modern AI changes parts of the debate. A task description is not the entire situation in which a person makes a judgment. The MIT Press description of his work is a good starting point.

My practical position is narrower than a claim about what is ultimately possible. I do not want to design systems that assume human judgment will disappear.

Keeping a person responsible for the goal, the important constraints, and the final acceptance is useful even if AI becomes much better. It prevents better execution from being confused with better judgment.

Why I use this idea

UCA gives me a practical way to look at a task:

1. What part of the work can be performed through software?
2. What can be checked automatically?
3. Which choices still depend on human judgment?
4. Where should the system stop and ask for a decision?
5. Who remains accountable for the result?

Once those questions have answers, the design usually becomes clearer. Automate the loop around the work that can be evaluated. Keep ambiguous choices visible. Improve the environment and the checks before assuming a smarter model will solve the problem.

AGI asks how capable machines may become. UCA asks what becomes automatable before we know the answer.

That second question is the one I can use today.

I develop the practical side of this idea further in The AGI Feeling Is Delegated Agency.