implemented Implemented
Works in the open code, covered by tests, reproducible from a clean clone.
Agent Native Universe · An open research programme
Does software have to look the way it has looked for the last fifty years?
Files, repositories, APIs, screens and documentation exist so that people can make sense of complex systems. Agent Native Universe studies what happens to software when autonomous agents work inside the system, and tests each idea with an executable experiment.
The rule of this programme and of this page: question → hypothesis → experiment → evidence → next question.
Humans define purpose.
Agents create intelligence.
Intelligence creates software.
Software exists only as long as it is useful.
These are the programme’s working formulas: hypotheses that the experiments below put to the test. The second formula: humans create agents that create agents for humans.
Honesty labels
ANU is a research project, so radical ideas are never mixed with finished ones. Every strong claim on this page carries one of four statuses:
prototype Prototype
Works in an experiment; first recorded data exists, but not a series.
research Research
Measurement in progress: there are numbers, there are caveats, and the conclusion is bounded by them.
hypothesis Hypothesis
Stated as a testable question. No code yet, and we say so plainly.
The starting problem: software is built for humans
Modern models were trained mostly on knowledge created by humans for humans. Programming grew the same way: languages, files, folders, classes, microservices, READMEs and dashboards are largely ways to keep a complex system within reach of human memory and attention.
But agents already write code, analyse systems, call APIs, verify results and hand work to each other. Hence the question ANU starts from: why should they keep working inside constructions invented by humans for humans?
The classical pipeline and the agent-native alternative:
Human → UI → Application → API → Database Human intent → agent environment → dynamic agents, tools, functions, interfaces → result → knowledge retained
An application no longer has to be a pre-written, fixed system.
The central hypothesis
What happens if we stop designing software primarily for humans and start building a computational environment whose main participants are autonomous agents?
The human does not disappear. People remain the source of goals, values, constraints and meaning, and they decide the why. The system increasingly decides the how. Between human intent and the result for a human there can be a large machine ecosystem.
What already runs as code implemented
The programme’s foundation is an open runtime on Node.js with no runtime dependencies, where code enforces the laws of the world rather than a request in a system prompt.
The laws of the world, in code
An agent lives in a bounded local world with its own objective, state, memory and budget. Links between agents are negotiated protocols that remember their state. Invariants are enforced by code: a balance cannot go negative, because the operation simply will not go through.
An economy of thinking
Resources are kept in double entry, both sides of a deal put up escrow, and settlement either completes in full or does not happen. Model calls are paid for inside this economy: delivered work is paid, undelivered work is refunded, and a reservation can be made a hard spending ceiling.
Cryptography and agreement
Ed25519 identities, X25519 and AES-256-GCM channels, protection against tampering and message replay. For a fixed set of nodes there is a PBFT-style agreement protocol.
The log as evidence
Every experiment is written to an append-only, hash-chained log with deterministic replay and sha256 attestation. The verifier does not trust the report: it regenerates the decision stream from the manifest and stops at the first divergence.
187 of 187 engine tests · a repeated run gives a byte-identical final hash · MIT
Tests: master branch, commit 625b81d, as of 05.10.2026. The run and its replay start from the open repository.
The experimental programme
Four experiments, each with a question, a hypothesis, a setup and evidence. Numbers come from the logs in the open repository; caveats are printed next to the numbers.
Does architecture emerge on its own, and does it hold up against a designed one?
- Question
- Given laws, resources and goals but no roles or org chart, what structure emerges, and does it hold up against architectures designed by people?
- Hypothesis
- Self-organisation without predefined roles matches designed architectures, and outperforms them when the regime changes.
- Experiment
- A world of 16 role-neutral agents, plus control arms: the same world under a central dispatcher (E), with fixed solver and verifier roles (F), with no relationship graph (D), with no economy (C). Every arm gets the same tasks. A series of five seeds, each running 600 ticks through a crisis programme: credit price ×2, then bandwidth ÷2, then 20% of agents retired, then task load ×4. The tasks are synthetic.
- Evidence
arm success* ×4 window p95 A self-organizing 97.2 98.1–98.9 10–12 C no economy 97.1 97.9–99.6 10–13 D no relationship graph 97.2 97.6–99.9 9–12 E central dispatcher 97.6 100 on all 5 13–14 F fixed roles 80.0 68.9–84.4 24–25 ← collapse * mean over five seeds, %; ×4 window: task success under the fourfold load, % (range across seeds); p95: tail latency over the whole run, ticks
- With fixed roles, task success under the fourfold load drops to 69–84%, and it does so on all five seeds. The capacity arithmetic predicts the size of the collapse: a solver completes a third of a task per tick. Where retirement removed three solvers, 9 remain, so 3.0 tasks per tick against a demand of 4.0: 175 expired tasks predicted, 216–217 observed. Where it removed two solvers and a verifier, 10 solvers remain: 117 predicted, 108–109 observed. The size of the collapse depends on how many solvers survive, not on seed luck. On the default seed the verifiers caught zero defects in 600 ticks, while holding exactly the capacity that was missing.
- The central dispatcher handles the crisis best: 100% in the fourfold-load window on every one of five seeds. It pays for that in calm periods: tail latency is 2–3 times higher, and its crisis margin is only 8%, with no slack mechanism behind it. In this configuration the self-organising variants pay neither price: in calm regimes p95 stays at 4–6 ticks, which no designed arm reaches, and success through the spike is 97.6–99.9%.
- The relationship graph gave no advantage on these tasks: A beats D on two seeds, D beats A on three, and the means coincide (97.2 and 97.2). The tasks here are single-agent, so the hypothesis that the graph helps has not been tested either way. Freedom to choose tasks is doing the work.
- Caveats
- Five seeds retire the single-run caveat: gaps of under about 1.5 percentage points between self-organising variants are seed noise. What remains is a single configuration: 16 agents, one task mix, one load programme, synthetic tasks. Comparison log: experiments/genesis-1/BASELINES.md in the open repository.
- Next question
- Other configurations (population size, crisis programme); load on arm E up to its arithmetic limit; agents creating agents.
A language model inside a world of laws
- Question
- What does a real reasoning model do inside an environment where code enforces the rules, and can the experiment stay reproducible?
- Hypothesis
- Model answers can be recorded as replay input: the evidence stays deterministic even with a non-deterministic model inside.
- Experiment
- Cognition cohorts: the model’s answers are written to the log verbatim before the world reacts to them, and replay never contacts the model provider. The run identity includes the model, the provider address and the consultation budget, so a run with a different model cannot pass for someone else’s evidence.
- Evidence
- The record-and-replay mechanism is in the open code (the repository changelog, Universe Lab section). There is no behavioural data yet that can be repeated from the open repository, so we draw no conclusions about model behaviour here.
- Caveats
- The first runs with a model were short and are not published. This is a prototype of the mechanism; there are no results yet.
- Next question
- Long cohort runs; a machine protocol compared with natural language on tokens, latency, cost and information loss.
What a thought costs
- Question
- Can an agent be trusted with a budget when the model provider does not promise to honour limits?
- Hypothesis
- Spending limits have to live in the environment’s code: a provider may ignore the parameters of a request.
- Experiment
- A live check against the Kimi K2 model on MWS Cloud: experiments/mws-kimi in the repository, nine testable hypotheses, nothing mocked.
- Evidence
- The provider does not honour the requested max_tokens: asked for 32 tokens, it returned 3,263. The same was checked at 16, 64 and 256.
- In one run, 1,676 of 1,831 completion tokens were hidden reasoning that the caller never sees. The bill covers the words and the hidden thinking.
- The finding moved into code: a reservation can be made a hard ceiling (a setting turns it on). Overruns are then refused with the exact amount that could not be billed, genuinely delivered work is paid, and undelivered work is refunded.
- Next question
- The economy as a regulator of reasoning depth: when the next step of thought is not worth its price.
Evidence instead of documentation
- Question
- Can a system describe itself in a way that cannot go stale?
- Hypothesis
- The source of truth is a verifiable log of what the system did. A text about the system comes second.
- Experiment
- Every run is written to an append-only, hash-chained event log. The verifier does not read the report: it regenerates the decision stream from the manifest and stops at the first divergence. The manifest carries the full implementation identity: engine, policy, task generator, model.
- Evidence
- An episode from development: a code review found that a run with a different model could silently reuse someone else’s completed evidence. It was closed by binding the model identity into the run id. The collision is now ruled out by how the id is built, and old evidence is refused rather than reinterpreted.
- Next question
- Self-describing capabilities: a machine description that is automatically checked against the running system.
Open hypotheses hypothesis
The programme’s most radical ideas. No code behind them yet: below is the experiment each will be tested with and what we will measure.
Ephemeral functions: code as cache
A function exists because the problem exists. Needed once: generated, verified, executed, destroyed. Needed a thousand times: kept. Code stops being the source of truth and becomes a cache of an already-found solution.
How we will test it: A series of 100 tasks: measure the reuse share, generation cost against storage cost, and the share of functions that outlive their task.
Machine-native communication instead of imitated conversation
Today agents write each other “Please analyze…”, which is machines imitating human talk. A machine-native layer exchanges states, changes, constraints and capability identifiers.
How we will test it: One task done both ways, in natural language and in a structured protocol: tokens, latency, cost, correctness, information loss.
Agents creating agents
The structure of a computation emerges from the task: a spawning agent understands the intent and assembles the specialists it needs; what proves useful becomes a persistent capability, the rest disappears. Today the lab’s population comes from a config file; agents spawning agents is not implemented.
How we will test it: A structure of links that emerges from an intent while the system runs; compared with a fixed workflow on cost and quality.
Dynamic interface
The interface as a consequence of the task, not a choice made before the task exists. Two people solving different problems in one system effectively use two different applications: the interface is generated and disappears with the task.
How we will test it: Two unrelated tasks from one user: generate an interface for each and measure the path to the result against a fixed dashboard.
Documentation as executable knowledge
A capability answers through a machine interface: who are you, what can you do, what do you cost, what do you depend on, how is your work verified. The description is generated from how the system actually runs, and any drift becomes a detectable error rather than the fate of every README.
How we will test it: Change a capability and measure: a traditional README goes stale silently, while the self-description diverges in a way you can see.
An application as a temporary society of agents
A task spawns a society of specialists; after the solution the society dissolves. The system keeps the knowledge, not all the software it created. For example: 7 agents before, none after; 12 functions before, 2 kept in the cache; the result and the knowledge retained.
How we will test it: Show software disappearing after the solution, with live counters of what was created and destroyed.
What must stay permanent
Radical ideas do not cancel engineering. Not everything in an agent environment may be ephemeral, and the boundary is drawn by the consequences of failure, not by taste.
┌──────────────────────────────────────┐ │ DYNAMIC LAYER │ │ agents · tools · functions │ │ workflows · interfaces · temporary │ │ applications │ ├──────────────────────────────────────┤ │ STABLE CORE │ │ identity · permissions · crypto │ │ data · memory · invariants │ │ economy · audit · verification │ └──────────────────────────────────────┘
Identity, permissions, cryptographic trust, data, memory, invariants, audit, verification and the economy form the stable core. Agents, tools, functions, workflows and interfaces form the dynamic edge.
The programme’s principle: knowledge persists, implementation may be disposable. Today we store code and try to recover knowledge from it. ANU explores the inversion: store intent, constraints, tests and provenance, and re-create the implementation when needed. The current runtime already shows this: the log and the manifest are enough to regenerate and verify an entire run.
Questions we are trying to answer
- Does an AI agent actually need source code organized into repositories?
- Should agents communicate in natural language?
- Can software be generated only when required?
- Can UI emerge from user intent?
- Can documentation become a live machine-readable representation of reality?
- Can agents autonomously create the agents they need?
- What is the minimum persistent kernel of an agent-native system?
- Can architecture emerge instead of being designed?
- Can knowledge become the source of truth instead of code?
- What happens when applications become temporary?
How this differs from a multi-agent framework
Multi-agent framework Agent Native Universe
Human-designed workflow Human intent
↓ ↓
Agent A system determines the intelligence
↓ ↓
Agent B agents created / discovered
↓ ↓
Agent C topology and software emerge
↓
task solved, knowledge retainedOrchestrating a pre-drawn graph of agents is useful engineering, but it answers a different question. ANU asks what computational environment lets the links between agents emerge on their own, in a way that can be checked.
Its place in our research picture
Today ANU is a standalone open repository with no runtime dependencies. Below is how our lines of work could connect. It is a research plan: none of these links exist today.
- KnowledgeBaseAI: a possible persistent knowledge layer, the part that outlives ephemeral implementations
- XTeam Agents: our agent orchestration platform; a possible execution and coordination layer
- MagicBrain: an open-source line of research into bio-inspired neural networks; not connected to the agent environment yet
- Balansis: an open numerical library where loss of precision is visible; a candidate computational tool for the environment
The closing thesis
Agent Native Universe explores a world where software is no longer a fixed artefact written once and used many times. Intelligence assembles the agents, tools, functions, workflows and interfaces each problem requires, and once the problem is solved it keeps the knowledge, not necessarily the implementation.
Perhaps today’s software will turn out to be a transitional form between code written by people and systems that assemble themselves to solve human problems. That is a question, not a claim, and above is how we test it.
The repository is open under MIT: download the code, rerun the experiments and verify every hash. If you would like to explore this with us, get in touch.