GoClaw: Roadmap to Level 4 (Autonomous Digital Workforce)

Level 4 is an AI employee: an agent that runs a business procedure from start to finish on its own, inside tools the platform provides, under rules people set (Autonomy Levels). This page covers three things: the principles that decide what GoClaw builds toward that goal, what is in place, and what is still open. It changes when a capability lands or changes. The platform philosophy is in Level 4: AI Employees.

🧭 Principles

1. Procedures, not prompts. Work that must come out right every time is a SOP. A SOP has steps, each step gets only the tools it needs, and Go code checks each step's answer before the next one starts.
2. Code does the deterministic work. Queries, calculations and calls that repeat for every row of a list run as SQL, data tools and MCP map steps. The model reasons about the results; it is not used as a loop.
3. Zero trust by default. The agent works through built-in tools and connected MCP servers only. Shell commands are sandboxed and file access stays in the workspace. No tool can write config.yaml or the plugins directory, and every webhook authenticates.
4. People hold the controls. Approval steps, hook rules on tool calls, roles and admin-only files decide what an agent may do and when it must ask.
5. Failures are visible. A step whose check fails is retried or ends the run. Every run records each step's answer. A run that fails, escalates, cannot resume after a restart or waits for approval sends a notice to sop.alerts.
6. One general platform. A customer's need becomes a general capability, or advice on how to write their SOP. GoClaw does not grow customer-specific code.
7. Cost has a ceiling. Token budgets and per-run limits stop runaway runs, and large results stay out of the prompt until the model asks for a part of them.

🟢 In place

Procedures (SOPs) — SOP guide

• Step-by-step runs with state: each step's answer, attempts and tokens are stored, and a step can call only the tools listed for it.
• Checks in Go: success_check (json, or expr: on the values a step publishes) decides whether a step passed. A step's constraints are rules the model is given. A failed check is retried. failure_mode then carries on (retry), fails the run (abort) or hands it to people (escalate).
• Branching: on_failure_goto jumps to a recovery step. end_run_if ends a run early, and skip_if skips a step.
• Map steps: for_each runs a step once per item. mcp_call calls an MCP tool per item with no model call in between.
• Human-in-the-loop: a step with requires_approval suspends the run until someone approves or rejects it.
• Triggers: cron schedules and authenticated webhook routes start runs.
• Restarts: steps have time limits, and an effects journal records what a step already did. A run cut by a restart resumes within sop.resume_window; past that, a notice goes to sop.alerts.
• Prerequisites: a SOP's prerequisites (tools, views, permissions) are checked before it runs. capability_request lets the agent hand a missing capability to IT (Tools and MCP).
• Undo (opt-in): a step may name a rollback_command. When a run ends with abort or escalate, the completed steps' commands run newest first.

Events and channels

• Channels: MS Teams, Discord, Facebook Messenger, Telegram, Signal (one-to-one chats), WebSocket, REST and an OpenAI-compatible API (Channels).
• Alerts into investigations: managed hooks for GitLab, Graylog, Grafana, SonarQube, Zabbix, Uptrace and Wazuh turn an event into a SOP run (Automation).

Memory and learning — Memory Engine

• Facts with a source: facts come from what people said and what tools returned, never from the agent's own earlier answers. They are stored as memory and as a knowledge graph.
• Conflicts and hygiene: belief revision decides between conflicting facts, and consolidation merges duplicates every night.
• Learning from errors: a failed tool call is diagnosed in the same turn and pointed at approved Saved Queries, tool presets and wiki pages. No error lessons are stored.
• Organisation knowledge: the org wiki, and a Wiki.js mirror.

Delegation — Subagents and Jobs

• Subagents and background jobs: a managing agent delegates work under a spawn policy.
• Agent-to-agent messages: off unless tools.agent_to_agent.enabled is set.

Guardrails — Security

• Loop detection: repeated calls of the same tool and repeated errors are caught and stopped.
• Hook rules: an admin can block a tool call, require approval for it, send a notice, or ask an outside check, which fails closed.
• Read-only data access: db_query checks the SQL, runs it in a read-only transaction under server limits, and confines a delegated run to its role and subject.
• Sandbox: shell deny lists, workspace-only files, SSRF protection for outgoing HTTP, and an encrypted secrets vault.

Cost and reliability

• Token budgets: daily limits per agent and per session, an hourly limit per session, a global daily limit, and max_run_tokens per SOP run (Token Budgeting).
• Large results: results over the size limit go to the output store and are read in parts with read_output (LLM Optimization).
• Models: each agent can list fallback models, and an overloaded provider is retried (Provider Fallback).
• Runtime: a bounded worker pool runs tools, and a panic ends its request, not the gateway. goclaw doctor checks the setup (CLI), and OpenTelemetry traces each run.

🛠️ Still open

1. Dynamic negotiation. Agents do not yet weigh each other's workload or skills to share out work. Messages reach an agent through static bindings, and the model picks a subagent with the subagents tool.
2. Atomic rollback. A failed run undoes only the steps that name a rollback_command. There is no transaction across steps, and nothing reverts files or database changes on its own.

Beyond Level 4, Level 5 Vision describes agents that propose goals, SOPs and tools for people to review. None of it is implemented.