How an AI agent in AxonWeaver turns a task into an executable business process: from the manifest to a Temporal workflow inside the project's container. There is no free-form prompt: every step is a call to a registry tool, checked against a contract and written to the session log.
A business developer sets the task through their own agent. The registry defines the required sections for each task type, open questions are stored as separate rows, and machine rules are checked by code. While something is missing, the task cannot be handed to the analyst, and the platform shows exactly what is missing.
The analyst opens a session in the workspace and hands its id to their agent: Claude Code or any other MCP client. The id travels with every call, nothing can be written without it, and every call shows up in the log on the operator's screen.
The order of work comes from the agent's skill, and the tools themselves guard the key transitions: no schema change without a preview, no deploy without checked code.
Where the agent works, where the platform checks, where a person decides
Before proposing anything, the agent reads the registry: node templates, processes and their graphs, entities, external APIs, interface endpoints, the project's real database schema and how far it has drifted from the registry. Whatever can be reused is reused.
The agent writes the plan and its manifest: ten required sections, from the module and entities to the process graphs and the package. The platform checks the manifest until no errors remain. Everything is referred to by name: an invented UUID or a placeholder such as TODO is an error. Where it would have to guess, the agent asks, and while questions are open the manifest is not final. A person agrees the plan.
When the process needs new entities or fields, the platform shows a preview: every registry row, every DDL statement and the other projects that will see drift. It is applied only after an explicit yes, and only the preview the person saw. That preview is signed with sha256; if the registry changed in the meantime, the preview is made again.
The agent writes Temporal workflows and activities in Python against the code contract. The platform checks the code before storing it: allowed imports, no I/O in a workflow, a timeout on every call, Google-convention docstrings through ruff. Only code that comes back valid is stored. It sits on the draft and changes nothing by itself.
With a person's consent the code goes into the Temporal worker inside the project's container; each project has its own namespace and task queue. Before loading, the platform imports every file once more and runs the workflows through Temporal's sandbox. If anything is wrong, the worker keeps its previous code. The project's APIs are not restarted, and after a restart the container brings back exactly what was deployed.
This is a real run: activities call their APIs, so a person agrees the input. The answer is the result, or the error with its chain of causes. External providers can be replaced by the package's stand-ins for the run.
Every created object must be described. Reviewing existing descriptions is mandatory too: the agent checks them against the code and reports what disagrees. Someone else's text is rewritten only after the diff is shown and confirmed, and every description keeps its provenance: written by the agent or checked by a person.
Seventeen platform activities are registered in every project's worker. The agent calls them by name instead of writing them again, so waiting for a person, working with data and reaching outside work the same way in every process.
On a cron schedule from the manifest, on a partner webhook signed with HMAC, on a call to an interface endpoint, and on a coordinator signal when another orchestration completes. Schedules and webhooks are reconciled on every deploy.
The process waits for an employee's decision: the task lands in a workstation queue, it can be assigned, postponed or escalated, an SLA breach shows in the queue, and the decision returns to the process as a signal.
Insert, select, update and delete in the project's tables with no SQL in the code. The table and every column are checked against the catalog on each call, values are always passed as parameters, and an update or delete without a condition is refused.
A call to an external address where a provider's refusal is a branch of the process, not a crash. The platform's internal token is never attached to such a call. Another process of the project can be run with its result awaited.
A screen is declared as data: a queue, a card, an action, a report or a dictionary. The platform checks roles, permissions and translations in three languages and hands out the screen contract for FlutterFlow. A declaration with errors generates nothing.
A process reads and changes roles, the permission matrix, the interface dictionary and the access log only through platform activities, one section at a time. A project cannot edit its way past its own door.
The processes of one contour are gathered into a package named domain.contour. A package is deployed, verified and undeployed in one operation with a report per item: deployed, refused or skipped. Verification looks at the manifest, the code, the deployment and the schedules.
Credit bureaus, mandates, payouts and e-mail live in test environments with thin data and sometimes go down. A package carries a set of stand-ins: for every provider call it names what answers instead. The processes do not change: the provider's address comes from the project's data, and a stand-in repoints only that.
A drill-down through the C4 levels is rendered from the registry, and on deploy its state is frozen together with the process version. The same model builds the project's MkDocs site in Russian and English, with a code reference from the docstrings and every finding on one page.
The project and external systems: external APIs, the FlutterFlow app
Central backend, project container, orchestrator, Temporal
Business process → orchestrations → atomic processes
Graph node → generated Python → project tables
A refusal reaches the agent with a code and a path inside the manifest, so the agent fixes its own mistakes. A person sees only what needs their decision.
{
"target_module": {
"mode": "existing_namespace",
"namespace": "loans"},
"package": "servicing.core",
"entities": [
{"mode": "create", "name": "LoanNote",
"kind": "ENTITY",
"description":
"A note an operator leaves on a loan application"}],
"entity_attributes": [
{"mode": "create", "entity": "Loan",
"name": "notes_count",
"data_type": "integer", "default": 0,
"description":
"How many notes operators have left on the loan"}],
"process_templates": [
{"mode": "create",
"name": "servicing_core_loan_note",
"process_type": "BACKEND_PROCESS",
"process_layer": "ATOMIC",
"description":
"Stores an operator's note and counts it on the loan"}],
"process_graphs": [
{"template_name": "servicing_core_loan_note",
"nodes": [
{"node_ref": "Start", "kind": "START"},
{"node_ref": "SaveNote",
"node_template": "db_insert_record"},
{"node_ref": "Finish", "kind": "END"}]}]
}An example from the agent's skill: a new entity, a field on an existing one and a one-step process. Everything by name, every created object described.
Eight business processes of a lending system for South Africa went through this pipeline: requirements → registry → agent → package → Temporal.
Demo access, an architecture walkthrough and a timeline estimate for your domain.