Step 1
Model the operating world
Define the entities, relationships, events, and constraints that matter in your landscape so agents inherit a shared model of reality.
Build bespoke agent systems by giving your development loop a governed world to operate inside.
world-runtime is for internal platform and development teams building systems for their own landscape. It is tech-stack agnostic by design, fits alongside your chosen models, tools, services, clouds, and workflows, and can serve as one upstream dependency in a broader agent-first build stack.
The point is not to prescribe the whole harness. It is to give that harness a runtime where state, proposals, simulation, policy, approvals, and provenance stay explicit when decisions start to matter.
The reframe
Many teams already have the harness. What they do not have is a stable world behind it.
Agentic development loops are getting stronger: coding agents, test automation, review loops, deployment paths, observability, and tool access are becoming more capable every quarter. That improves productivity, but it does not by itself create a governed operating world.
world-runtime fits at that layer. It gives the loop explicit state, durable event history, policy boundaries, simulation branches, approval paths, and provenance so teams can build systems that are not only fast, but inspectable.
Explicit world state
Durable event history
Policy boundaries
Simulation branches
Approval paths
Decision provenance
A practical build pattern
This is how an agentic loop matures from smart automation into an inspectable decision system.
Step 2
Connect your existing stack
Bring in systems of record, services, tools, and workflows without turning world-runtime into a mandate on your app framework, cloud, or provider choices.
Step 3
Expose stable runtime surfaces
Use the App Server, public API, and SDK as durable build surfaces for internal tools, clients, and agent-facing workflows.
Step 4
Let agents inspect and propose
Have agents work against explicit state and submit candidate proposals with evidence instead of mutating consequential state through side channels.
Step 5
Simulate before commitment
Branch possible futures when the downstream cost is real so teams can compare outcomes before turning a recommendation into action.
Step 6
Apply policy and operator review
Keep denials, approvals, escalation, and intervention above reasoning so humans and agents stay aligned on the same decision record.
What makes this different
The shift is not just more capable agents. It is a runtime that distinguishes thought, proposal, and commitment.
Generic agent stack
With world-runtime
Agents coordinate through prompts, tools, and scattered service assumptions.
Agents operate inside a governed world model with explicit state and inspectable history.
Mutation is often mixed directly into task execution.
Proposal is separated from commitment so consequential change stays reviewable.
Evaluation happens after the action or only in logs.
Simulation can compare branches before commitment where consequences matter.
Guardrails live in conventions around the agent.
Policy sits above reasoning and can deny, warn, escalate, or require approval.
world-runtime does not dictate your app framework, cloud, model provider, orchestration layer, or internal tooling. It gives those choices a governed substrate when they need to act against consequential state.
Builder outcome
Keep your stack choices. Gain a governed substrate for how agents participate in the system.
This is the opportunity for internal teams: build bespoke systems for your own operational landscape without settling for a generic copilot pattern. world-runtime helps you structure the system so humans and agents can work from the same state model, compare futures before commitment, and keep the decision trail legible after the fact.
Developer quickstart
The shortest path from orientation to a working builder flow.
Public API v1
The supported runtime interface for integration and application development.
SDK
Code-level entry points for teams building bespoke systems on top of the runtime.
world-runtime may be one of several upstream dependencies in your architecture. That is part of the point: it gives internal teams a strong runtime layer without forcing the rest of the stack into one prescribed shape.