OperationalPrograms that
produce programs.
An AI agent creates or modifies a persistent executable graph. The graph can then be inspected and run independently of the authoring conversation.
A working core. An open product
question.
Agent-built
workflows.
Explicit effects.
Observable
execution.
A technology core for creating and running processes authored by AI agents — with a clear account of the operations they can perform.
Explore the idea
PROGRAM / 001
Operational
graph
02 / INSPECTDeclared effectsWhat it can do
03 / EXECUTERuntime & traceWhat happened
THE PROGRAM OUTLIVES THE
CONVERSATION
01 / A process that lives in time
The agent finishes.
The workflow keeps going.
Real-world tasks take longer than a conversation. They cross systems, wait for people, and need to act on what happens next.
THE REQUEST
“When a purchase request over €1,000 arrives, notify the owner. A day later, check its status. If it’s still open, escalate to the team lead.”
Illustrative scenario · connected systems assumed
PURCHASE REQUEST FOLLOW-UPInteractive illustration
- ↳Request arrivesCheck amount > €1,000
- ↗Notify the ownerSend a message
- ◷Wait one dayPreserve execution state
- ↻Read current statusCheck the system again
STATUS AFTER THE WAIT
Escalate to the team lead
END
The request is still open. Send the follow-up to the responsible lead.
This explores the logic locally; it does not run a workflow or contact any service.
01 The agent produces a persistent program.
02 Waiting is part of the execution model.
03 The next action uses fresh information.
02 / From creation to informed approval
What could it do?
What did it actually do?
These are different questions. Effect declarations describe possible operations. Execution history shows the steps and results of a particular run.
Give the people responsible
something concrete to review.
Our most ambitious use case: an agent creates or changes an automation, and the process owner and information security team receive a structured account of its capabilities before deciding whether to approve it.
That account starts with the operations declared by components and assembled from the graph’s structure. Its coverage and unknowns matter as much as the effects it lists.
Approval should be grounded in the executable program and its contracts.
We are exploring how to turn that foundation into reliable evidence for approval, change review, and runtime enforcement.
EFFECT REVIEW / CONCEPTTarget experience
Purchase request follow-upILLUSTRATIVE MODEL
RESOURCE / OPERATIONPOSSIBLE EFFECT
purchase_requestsREAD
Read request details and current status.
messagesWRITE
Notify the request owner and, if still open, the team lead.
messages+ RECIPIENT
Also send the escalation to the purchasing lead.
REVIEW QUESTION
Are these reads and notifications appropriate for this process?
Declarations describe capabilities; they are not enforced permission boundaries today. This preview is not a live approval interface.
AVAILABLE FOUNDATION
Effect declarations
Static validation
Execution
visibility
PRODUCT DIRECTION
Evidence for approval
Review of capability changes
Enforcement of approved limits
03 / Under the hood
A language for agents.
A runtime for their programs.
Operational Graphs combines a declarative language, an asynchronous runtime, and an explicit model of effects.
THE TECHNICAL DIRECTION
Agent-authored, asynchronous,
type-safe, interface-oriented
metaprogramming.
Programs that
Asynchrony
as a primitive.
Waits, external events, and human responses belong in the execution model. The runtime preserves state and resumes the process when it is ready to continue.
Explicit interfaces.
Known operations.
Agents compose operations with defined inputs, outputs, and effects. New capabilities enter through components with explicit interfaces, rather than arbitrary inline code.
Types describe data.
Effects describe actions.
Data contracts and effect declarations provide a foundation for checking a program and understanding its interactions with connected systems.
Today: static validation and descriptive effect manifests. Next: full type safety, stronger runtime contracts, and enforcement of effect boundaries.
04 / One core, several possible applications
Where could this be useful?
We have a working technology core. We are researching which problems and product forms make its properties most valuable.
Internal operations
Coordinate requests, documents, onboarding, reminders, and escalations across people and systems.
Long-running agent work
Run multi-step assignments, wait for an agent’s result, and continue with visible execution state.
Cross-system exceptions
Spot a discrepancy, gather context, and route a case to the person who can make the decision.
These are candidate applications, not a catalogue of ready-made solutions.
05 / An invitation to share your experience
Bring a real story.
Help shape what comes next.
We are talking with people who have built, requested, approved, or maintained automation — to understand where this technology could help and what would still be difficult.
FOR OUR CONVERSATION
- A process you wanted to automate.
- How you solved it, or why it was put on hold.
- What it took to approve, change, or maintain it.
A successful example is just as useful as a difficult one. No technical preparation is needed.