GoClaw Level 4: The Autonomous Agentic Platform

GoClaw is built to run business procedures (SOPs) reliably in any industry: banking, telecoms, logistics, IT operations. Each procedure has its own steps, data and approvals, so the platform supplies only what every procedure needs. Code checks the work, and the model does the reasoning in between. This page describes that design. What is in place and what is still open is in Roadmap to Level 4.

🎯 Platform Philosophy

Decoupled execution. A request mixes two kinds of work. Deterministic work, such as fetching rows, adding numbers or calling an API once per item in a list, has one right answer. Reasoning work, such as reading a result, choosing what to do next or writing a reply, does not. GoClaw gives the deterministic work to code:

• SQL through db_query and saved queries;
• calculations through calc and json_transform;
• one MCP call per item through mcp_call map steps.

The model reasons about the results instead of repeating a tool call for every row. A SOP author makes the split explicit: a step can run approved saved queries with no model call at all (SOP guide).

🏗️ Platform Capabilities

1. Capability gaps are handed to people

• What it does: a SOP lists its prerequisites (tools, views, permissions), and GoClaw checks them when the SOP is saved and again before each run. When an agent finds that a goal needs something it does not have, capability_request records what is missing, so IT or a DBA can provide it (Tools and MCP).
• Why: the agent knows the limits of what it may do and asks for more, instead of working around them. The infrastructure grows with a person in the loop.

2. The tools a call needs come with it

• What it does: a set of helper tools is offered in every context, a SOP step that lists only one tool included: read_output, json_transform, datetime, calc, regex and text_utils. A request that carries an image, a PDF, a document, a voice message or a link is offered the tool that reads it. Approved saved queries and tool presets that match the request are offered with the tool they run on.
• Why: an agent should not fail, or invent an answer, because a helper it needs was left out of its tool list.

3. Code checks the work

• What it does: a step's success_check is evaluated in Go: valid JSON, required fields, text it must or must not contain, length, a regular expression, or a comparison of the values the step published (expr:). A step that fails its check is retried, and then carries on, fails the run or escalates to people, as its failure_mode says.
• Why: a model's answer varies from run to run. The check does not, so a run either meets its success criteria or says that it did not.

4. Built to run unattended

• What it does:
  • A bounded worker pool runs every tool call, and a panic ends its request, not the gateway.
  • A SOP run cut by a restart resumes from its effects journal, or tells sop.alerts why it did not.
  • Token budgets and per-run limits stop a runaway run.
  • Old traces are pruned every night, and goclaw doctor and the health endpoints show whether the setup works.
• Why: an AI employee is only useful if it keeps working for months without someone watching it.

🔁 Knowledge that stays consistent

• Facts with a kind and a source: each fact the agent keeps has a kind, such as a fact or a preference. It comes from what a person said or a tool returned, never from the agent's own earlier answers.
• Conflicts: when a new fact contradicts an old one, a belief-revision step decides which one holds, and the change is recorded so it can be undone.
• Duplicates: a nightly consolidation removes near-duplicate memory chunks and merges notes that say the same thing (Memory Engine).