Skip to main content
The orchestrator used to hard-wire its routines: PARTIN answers, then APERAK, then the Zuordnungsermächtigungen, then the mailbox, the day steps, the reBAP reads, the confirmations, the contract check, the cases, the Slack log - each switched by a settings flag, each with its own interval buried in its code. They are process agents now: a definition in a ledger on the audit share, with the skills it carries, the triggers that wake it, its autonomy and its place in the order. This is PR 2 of the agentic process support design; it changes no behaviour, it makes the behaviour configurable.
The hash-driven day steps (aggregate, publish, submit) and the watchdogs (gate closure, trader deadline) stay in the orchestrator itself - design rule D11: the pipeline is never an agent. orchestrate() is now: the heartbeat, the agents before the day steps, the day steps, the watchdogs, the agents after the day steps.

The built-in agents

One per routine, in the old order. order below 100 runs before the day steps, above 100 after them. Each is seeded with one schedule trigger, every orchestrator run (every_minutes: 0), autonomy act (that is what the routines do today: they send), and enabled from its flag. A skill’s own interval and configuration check - its gate - stays with the skill, so a 6-hourly read is still 6-hourly whatever the trigger says; a gated skill that is not due is skipped in the run log, not run. A skill’s failure raises the same event the routine raised before (partin_answer_failed, aperak_failed, zoe_auto_failed, mailbox_sync_failed, fahrplan_bestaetigung_fehler, orchestration_error, case_sync_failed, slack_protokoll_fehler), so the alerting rules and the operator app see what they saw. The flags. Until they go (PR 6), a flag still switches its agent: a flag moved in the console or the environment sets the agent’s enabled and records a new version saved by settings. An operator’s own switch in the agents tab holds until the flag moves again.

Triggers

An agent with several triggers runs when any is due. A disabled agent is neither woken nor scheduled.

Runs

A run executes the agent’s skills in order. Per skill: ok with a small summary of the result, skipped with the reason (not configured, not due, no preview in a dry run), or failed with the error - a failure never stops the next skill. The last 50 runs per agent are kept (agent_runs.json), the agent’s state (last run, last trigger, counts) in agent_state.json, pending wakes in agent_wakes.json. A dry run (behaviour.dry_run, or dry_run: true on a manual run) runs the skills that have a preview (PARTIN answers, APERAK, ZOE, the mailbox, the cases, the Slack log) without writing, and skips the others.

Definitions

Every save is a new version with who and when; the version before goes to agents_history.json (50 per agent). A run records the version it ran on. The console tab Agenten lists every agent with its state and the day-steps divider, runs one now (dry or real), switches it, and edits or creates one with the form; the API does the same: Events: agent_saved on every create, change or delete; agent_run_failed (error) when a skill without a failure event of its own raises, or the agents could not be read.