A working core. An open product question.

Agent-built
workflows.
Explicit effects.
Controlled
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

Agent authorsintent → executable graph01

Operational graph

operationsconditionswaits

02 / INSPECTDeclared effectsWhat it can do

03 / EXECUTERuntime & traceWhat happened

THE PROGRAM OUTLIVES THE CHAT

01 / A process that lives in time

The agent finishes.
The workflow keeps going.

Real-world tasks take longer than a chat. They cross systems, wait for people, and need to act on what happens next.

Coding agentAuthors the draft graph

DRAFT WORKFLOWPurchase request follow-up

Interactive illustration

01EVENT

Purchase request arrivesStart on a new request

02CONDITION

Amount > €1,000?Continue above the threshold

END€1,000 or less

03ACTION

Notify the ownerSend a message

04WAIT

Wait one dayPreserve execution state

05ACTION

Read current statusGet fresh information

06CONDITION

Still open?Choose the next step

ENDAlready handled

07ACTION

Escalate to the team leadSend the follow-up

ENDFollow-up sent

EXPLORE STATUS AFTER THE WAIT

For a request above €1,000

Escalate to the team lead

The request is still open. Send the follow-up to the responsible lead.

END

This illustration shows authoring and possible execution paths. It does not run an agent 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

An AI agent has created a workflow that reads company data, sends messages, and updates records. Before it goes live, its owner and security reviewers need to understand what they are approving.

What are we approving
in this workflow?

Reviewing generated code can take substantial effort. Asking the agent to explain its work gives you another generated answer — one that may omit or misrepresent important behaviour.

Operational Graphs composes workflows from operations with explicit interfaces and declared effects. The graph’s structure provides a basis for inspecting those effects, with gaps in declaration coverage made visible.

Which data can the workflow read?
What can it change or send?
What capabilities does the proposed version add?

Approval should be grounded in the executable program and its contracts.

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.

DECLARATION COVERAGE

Missing declarations must remain visible as unknowns.

REVIEW QUESTION

Are these data reads and notifications appropriate for this workflow?

Declarations describe capabilities; they are not enforced permission boundaries today. This preview is not a live approval interface.

BEFORE A RUN

Inspect possible effects.

Review the operations declared by the workflow’s components and identify gaps in coverage.

AFTER A RUN

Inspect that execution.

Execution history shows the steps and results recorded for a particular run.

TODAY

Descriptive effect manifests
Static validation and execution history

OUR DIRECTION

Evidence for approval and change review,
backed by 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.

01 / AUTHORSHIP

Programs 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 chat.

02 / TIME

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.

03 / COMPOSITION

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.

04 / CONTRACTS

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 PRODUCT HYPOTHESIS

One platform for agent-built automation?

Could one enterprise product help teams find existing automations, adapt them with agents, review proposed changes, and run them in a trusted, observable environment? These may be connected capabilities of one product, rather than separate products.

01 / DISCOVER & CREATE

Internal Automation Studio

Search a shared catalogue for approved automations and their owners. Reuse a workflow or ask an agent to adapt it, test the changes, and submit them for approval.

02 / REVIEW

Automation Review Console

Compare a proposed version with the current workflow. Inspect declared data access and external actions, then route the change to process owners and security reviewers.

03 / EXECUTE

Enterprise Agent Runtime

Run approved applications and automations in a trusted sandbox. Preserve state, make each step observable, and pause for human decisions when needed.

THE PRODUCT HYPOTHESIS

A shared platform could make agent-built automations easier to find and reuse, safer to review, and easier to operate across business systems—without building a separate service for every process.

OTHER SCENARIOS

The core lets agents build relatively simple backends for almost any task. A few examples:

05 Backends for small services FRONTEND DEVELOPERS & STARTUPS

An agent assembles the server side for the task: an API, persistent state, webhooks, waits, and calls to external systems. The frontend stays yours, and the backend's effects are visible before they run.

06 Telegram and chat bots BOT DEVELOPERS & SMALL BUSINESSES

A bot as a program: it receives messages and button presses, waits for the user's reply as long as needed, and calls AI where text has to be understood. The Telegram integration already works.

07 CRM components SALES TEAMS & CRM INTEGRATORS

Lead qualification, next-step reminders, and pipeline stages as explicit program states rather than a pile of scattered triggers.

08 Personal automation INDIVIDUALS

Describe a routine in a chat and get a working program: bills, subscriptions, reminders, household errands. You can see exactly what it will do on your behalf.

09 Monitoring and response ENGINEERS & ANALYSTS

Watch a price, a status, an API, a website, or an alert from an existing security or compliance system. A hypothesis to test: an alert could start a workflow that gathers context, assigns an owner, requests human review, and escalates unresolved cases, reducing missed handoffs and delays.

10 Approvals and requests SMALL TEAMS WITHOUT A BPM SYSTEM

A form or message starts a chain of approvals and actions. Each step can wait for a person without losing state, including review of proposed policy, knowledge base, or support script updates.

11 Knowledge and support updates SUPPORT & KNOWLEDGE TEAMS

A hypothesis to test: recurring support issues could flag outdated or conflicting guidance. An agent could prepare a proposed change, route it to an owner for approval, and coordinate updates to the knowledge base and support scripts, reducing stale instructions and repeat work.

12 Self-service dashboards OPERATIONS LEADERS

A manager assembles or changes an operational dashboard using data from systems they can already access. An operational graph could connect those sources behind an existing dashboard interface. Hypothesis: teams could answer cross-system questions without waiting for a custom integration for every new view.

These concepts require additional product development and integrations. Trusted isolation, delegated permissions, and enforcement of approved effect boundaries are future capabilities.

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.

Agent-built workflows. Explicit effects. Controlled execution.

The agent finishes. The workflow keeps going.

What are we approving in this workflow?