AI & Technology
ClawdBots: Born, Execute, Gone
ClawdBots is our design for edge agents — on-site data collection from legacy and no-API systems, phoning results back to the platform. Scoped, ephemeral, human-approved.
If you have heard the word "ClawdBots" — in a demo, in a conversation, somewhere online — this is the plain-language explanation of our design for them and how they are intended to work.
ClawdBots is our design for edge agents. Their job would be to collect information that is better gathered on-site: from legacy software systems, from tools with no API, and anywhere computer-use helps a human-operated machine do what an API cannot. They would phone in to the platform with what they find. They would not hold the keys to your house — they are designed not to be CNX-core internals or privileged components of the central system.
For everything that does not need on-site collection — drafting, monitoring, analysing, preparing — we run ephemeral or persistent agents in the cloud. ClawdBots are a specific worker for a specific job: on-site, on-prem, collecting the data only a local process can reach.
ClawdBots as Edge Agents
Most of the work your AI agents do runs in the cloud — ephemeral agents created per task and destroyed after, or persistent agents that stay running for longer-horizon jobs. Both live in the platform, governed by the same Nest Protocol rules.
ClawdBots are different. They are edge agents: they run on-site (on your premises or close to the source systems) and phone in to the platform with what they collect. You deploy a ClawdBot where a cloud agent cannot reach — typically:
- Legacy software systems that pre-date modern APIs
- Software with no API at all, where direct interaction with the interface is the only option
- On-site data collection where computer-use — visually operating a screen the way a human would — is the right tool
A ClawdBot handles the local extraction. The platform handles the analysis, the decisions, and the approvals. ClawdBots do not hold privileged access to the core system — they phone in with their findings. They don't keep the key to the house.
Because each ClawdBot is scoped to its job, the keycard model still applies: every ClawdBot has a keycard. It only opens the doors it needs — and nothing it collects bypasses the approval layer that wraps every consequential action.
The Lifecycle: Born, Execute, Gone
Born for the task
When a request comes in — draft this supplier response, analyse this campaign, flag this anomaly — a ClawdBot is created specifically for it. It is given the identity, the tools, and the data access the task requires. Nothing more. It did not exist before this moment.Execute under scope
HUMAN APPROVED
The ClawdBot works within its defined contract: it can call the tools it was explicitly granted, access the data it was explicitly shown, and draft or prepare actions within its authority boundary. When it reaches a consequential action — sending a communication on behalf of the business, committing budget, publishing to an external channel — it stops. You see exactly what it intends to do and why. You approve or reject. Then the agent acts, or doesn't.Gone — nothing left at rest
When the task is complete, the ClawdBot is destroyed. The session ends. The credentials it used are not stored. The short-term working context for this task is discarded — there is no lingering process, no cached identity, no accumulated session state. What matters gets promoted to long-term shared memory; the working scaffolding does not persist. Between your requests, there is nothing to reach.
Born. Execute. Gone. That is not just a tagline — it is the architecture.
What ClawdBots Actually Do
ClawdBots are the agents that make up your AI Business Department — the specialists, the data collectors, the analysts. In practice:
- A ClawdBot drafts a supplier response from your Company Brain's record of that vendor's history.
- A ClawdBot monitors your campaign metrics and flags when something shifts outside the expected range.
- A ClawdBot prepares a reorder recommendation when inventory approaches a threshold — and surfaces it for your approval before anything is committed.
- A ClawdBot collects invoice data and compares it against contract terms, surfacing discrepancies for your team.
In every case: the ClawdBot prepares. You approve what matters. Then it acts — and when it is done, it is gone.
The Oversight Layer: Guardrails, Gating, Audit Trail
The Specialist is one half of the model. The other half is the oversight layer that wraps every Specialist's work.
Guardrails constrain what each ClawdBot can do. We build on the guardrail and role controls in the modern multi-agent frameworks we use, plus our own guardrail layer configured to the level of risk you're comfortable with. We don't reinvent the wheel. We configure it to your business.
Gating puts you in the loop on decisions that matter. When a ClawdBot reaches a consequential action, it stops at your approval gate. Consequential actions do not run without your sign-off.
Audit trail logs everything to a reviewable record. Every action. Every agent. Every time. When you or anyone else asks what happened and when, the answer is already there.
We are not a partner or certified affiliate of any AI or infrastructure provider.
Note
Every ClawdBot carries the governance qualifier that applies to all Connected Spaces AI Agents: properly managed and safely configured by expert humans, each agent operates within a defined authority boundary. Nothing consequential runs without your approval.
ClawdBots, The Nest Protocol, and Infrastructure You Own
ClawdBots run under the Nest Protocol, the architecture that governs agent lifecycle, permissions and controls. Qualifying customer-specific custom IP ownership starts in subscription month 13. This does not transfer the CNX framework itself or every platform component. Agree the transferable inventory, retained components, dependencies and handoff process.
For the full architecture — ephemeral execution model, six governance pillars, prompt injection defense — see Governance and Security.
Understanding ClawdBots in Plain Terms
ClawdBots are edge agents — specialists designed for on-site, on-prem data collection from legacy systems, no-API software, and anywhere computer-use is the right approach. Each one has a defined role, scoped permissions (the keycard only opens the doors its job needs), and a reporting line back to you on consequential actions. They collect, phone in, and prepare. They do not act unilaterally. When the task is complete, they are destroyed — no persistent process, no credentials at rest.
The lifecycle name — Born, Execute, Gone — is a literal description of how they work. Born: created per-request, given only the tools and data access the task requires. Execute: works within its defined scope and stops at your approval gate on anything consequential, financial, or irreversible. Gone: when the task is complete, the agent is destroyed. No lingering process, no stored credentials, no short-term working context carried to the next request. What is worth keeping gets promoted into the shared long-term memory layer — so the next task starts informed, not blank.
Guardrails are not a separate AI reviewing every output. They constrain what each Specialist can do in the first place — the tools it can call, the data it can reach, the actions it can take. Gating stops the agent at your approval gate when something is consequential. Consequential actions stop before they run, not after. That distinction matters.
Scoped permissions are architectural, not a setting someone can toggle. A support-role ClawdBot was never granted access to your cost ledger — the keycard only opens its own doors. No prompt, no workaround, and no other agent can grant it access beyond what it was explicitly given.
If something goes wrong, a person you authorize can stop the agent. That is set up as part of your guardrails, with limits on what it can see and do and a person approving anything consequential. Runs are bounded by design: each one has a step and time limit, and an approval request that nobody acts on expires on its own.
Explore which plans include your AI Business Department
Related
- Agent Platforms, Edge vs. Cloud — Which agents run on-site vs. in the cloud, and the SDK layer that connects them.
- Ephemeral AI Agents — What They Are — Short-term working context discarded; long-term memory preserved and shared — what that means in practice.
- The Nest Protocol — The AI Business Department structure: how specialists, guardrails, and gating fit together.
- Governance and Security — The full technical design guide: six pillars, human approval gates, infrastructure foundation.
- Your AI Team — How the full team of AI Agents is organised and how you direct them.