# 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](../architecture/autonomy_levels.md)). 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](level4_final.md). --- ## 🧭 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](../user-guide/automation/sop.md) * **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](../user-guide/tools_and_mcp.md)). * **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](../user-guide/channels/index.md)). * **Alerts into investigations:** managed hooks for GitLab, Graylog, Grafana, SonarQube, Zabbix, Uptrace and Wazuh turn an event into a SOP run ([Automation](../user-guide/automation/index.md)). ### Memory and learning — [Memory Engine](../architecture/memory_engine.md) * **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](../user-guide/saved-queries.md), tool presets and wiki pages. No error lessons are stored. * **Organisation knowledge:** the org wiki, and a [Wiki.js](../user-guide/wikijs.md) mirror. ### Delegation — [Subagents and Jobs](../architecture/subagents_and_jobs.md) * **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](../architecture/security.md) * **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](../user-guide/token-budgeting.md)). * **Large results:** results over the size limit go to the output store and are read in parts with `read_output` ([LLM Optimization](../architecture/llm_optimization.md)). * **Models:** each agent can list fallback models, and an overloaded provider is retried ([Provider Fallback](../architecture/provider_fallback.md)). * **Runtime:** a bounded worker pool runs tools, and a panic ends its request, not the gateway. `goclaw doctor` checks the setup ([CLI](../user-guide/cli-reference.md)), 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](level5.md) describes agents that propose goals, SOPs and tools for people to review. None of it is implemented.