The future of artificial general intelligence is a research question, not a finished product description. These guides make room for an ambitious systems thesis while keeping practical evidence and human responsibility in view.
01 / THE QUESTION OF GENERALITY
Broad capability needs a clear definition.
People use “AGI” to describe different ambitions: systems that perform a wide range of tasks, adapt to unfamiliar situations, learn new capabilities or match human performance across many domains. Those ideas are related, but they are not interchangeable tests.
Before making a claim, define the scope. Which tasks count? What inputs, tools and assistance are allowed? What happens on unfamiliar cases? How much human intervention is needed? A system that performs one benchmark well has not, by that fact alone, demonstrated general intelligence.
Capability, breadth and conditions all matter.
Success can depend on the surrounding software, selected tools, retrieval sources, human review or carefully prepared examples. Make those conditions visible so another person can understand what the result does—and does not—show.
Our thesis is that broader capability may emerge from better composition of specialised agents and supporting systems. That is a direction to investigate, not evidence that a swarm automatically becomes AGI.
A personal agent can own a bounded task. A team can divide work among roles, such as collecting evidence, comparing options and reviewing an output. The value of that separation has to be tested against the added complexity.
Choose a coordination pattern for the job.
Orchestrator and specialists: one role assigns work and assembles the result. This makes ownership clearer, but the orchestrator still needs good task contracts and error handling.
Peer-to-peer exchange: roles communicate directly. Define who resolves disagreement, how much communication is allowed and when the process stops.
Layered teams: smaller groups work on parts of a larger problem. Preserve the overall objective through every handoff.
Share context deliberately.
Useful shared memory can reduce repeated explanation, but access should be scoped by person, client, project and task. Preserve source provenance and freshness, and distinguish remembered data from trusted instructions. Define correction and deletion paths before memory becomes a permanent accumulation.
Start with the smallest architecture that can perform the task. Compare a multi-agent design with a single-agent workflow and with conventional automation. A simpler system may be easier to evaluate, operate and recover.
A system can improve without claiming that its underlying model is autonomously rewriting its own intelligence. Prompts, task decomposition, retrieval, tool selection, memory rules and evaluation criteria can all be versioned and deliberately changed.
Keep the failure case. Record the permitted input, expected result and what actually went wrong. Remove or protect sensitive data before using it for testing.
Form a bounded hypothesis. Change one part of the workflow where possible. State why it might help and which behaviour it could break.
Test beyond the original example. Use representative cases, held-out cases and regression tests. Avoid “teaching to the test” and calling it general improvement.
Review the trade-offs. Look at quality, escalation, cost, latency and failure behaviour. A gain in one measure can hide a loss in another.
Promote with an accountable owner. Keep a record of the candidate, evidence, reviewer and rollback decision.
Monitor after release. The environment changes. New tools, models, documents and user needs can invalidate an earlier result.
Be precise about “self-learning”.
Learning from feedback in a workflow is different from updating model weights. A proposed change is different from an approved deployment. Neither proves open-ended autonomous recursive self-improvement. Use the narrowest description supported by the evidence.
People need practical skills to commission, use and review agents. The aim is not to become an expert in every model, but to understand the contract between the person, the system and the work.
Exercise 1 — Rewrite an ambition as a task.
Take a recurring activity such as “keep us informed about suppliers”. Turn it into a bounded output: approved sources, a comparison format, a named reviewer and a finish line. Identify which decisions remain with a person.
Exercise 2 — Find the hidden permission.
List every tool or data source the workflow would need. Separate reading from writing. Ask what could happen if an external document contained instructions that conflicted with the task. Permissions should be enforced by software, not merely requested in a prompt.
Exercise 3 — Review a plausible failure.
Imagine a confident answer with a missing source, an outdated fact or a mistaken assumption. Write the check that should catch it. Then ask how the system should behave when the check cannot establish confidence.
Exercise 4 — Design the handoff.
Specify what a reviewer receives: the draft, source links, uncertainty, proposed action and any relevant constraints. “Approve” should mean something understandable, not merely continuing a screen animation.
An ambitious proposition becomes more credible when another person can inspect its assumptions. Before treating a prototype as a scalable business, assemble an evidence pack around a real workflow.
Problem: who experiences it, how it is handled now and why improvement matters.
Baseline: the simpler process against which the system will be compared.
Demonstration: what actually runs, what is simulated and what remains a proposal.
Evaluation: representative cases, failure cases, the rubric and results under stated conditions.
Economics: observed costs and operational work, without assuming a demo scales unchanged.
Control: data rights, access, human review, monitoring and recovery responsibilities.
Learning agenda: the next uncertainty to resolve, rather than a promise that every capability is already available.
We welcome conversations with people who want to turn that discipline into useful systems. A discussion is not an investment offer or a guarantee of technical or commercial outcomes.