Personal product / Managed agent infrastructure
Claw2Agent
From installation to a usable, protected workspace.
A personal product for managed OpenClaw setup and runtime management. Its implementation connects guided configuration, Telegram validation, entitlement checks, protected access, and recovery paths rather than stopping at a server-created message.
- My contribution
- My personal product around the OpenClaw runtime, covering the web experience and product-control layer. OpenClaw supplies the underlying agent ecosystem; this case does not claim a self-built agent engine.
- Current status
- New signups paused
- Built with
- Next.js, TypeScript, Cloudflare Workers, D1, R2, OpenClaw
The problem.
Trying a persistent cloud assistant can mean assembling a server, model access, Telegram configuration, and a usable console. When setup fails, users also need to know whether the runtime is starting, unreachable, offline, or actually ready.
What I worked on.
- Connected step-by-step setup to server-side entitlement, quota, framework, and connection checks.
- Worked on protected runtime access and explicit preparing, ready, offline, and failed states.
- Modelled asynchronous action ownership, lease expiry, bounded retry, and failure outcomes.
- Explored a separate synthetic intake workflow with missing-information checks, human review records, and default approved-row export.
Treat runtime access as a product state.
Check access before creating resources
The implemented setup flow checks the user's entitlement, framework access, quota, model configuration, and Telegram connection prerequisites.
Create or recover the runtime assignment
The control layer has paths for reusing existing or partially created resources, so receiving a create response is not treated as proof that an assistant is usable.
Derive availability from runtime evidence
Console access considers heartbeat freshness, health, tunnel, and access-gate conditions. A protected launch ticket is scoped to the owner and assigned resource.
Recover a timed-out action within a budget
Lease-based action handling can requeue an expired attempt or record a final failure after the retry budget is exhausted.
The product distinguishes an allocated resource from an assistant the owner can actually open, and makes failure and recovery explicit engineering concerns.
This walkthrough describes implemented control logic reviewed in code and isolated tests. Authenticated hosted setup, real cloud execution, and tunnel access were not verified end to end in the portfolio review.
The actual interface.
Under the hood.
- Application and authorization layer
- Next.js setup interfaces call server-side creation and access routes. Entitlements, quotas, ownership, and framework permissions are checked again on the server rather than relying on a hidden button or a client-side step.
- SQL state and asynchronous recovery
- Scoped action polling uses leases, attempt counts, and bounded retries. D1-backed application data and R2 artifact paths separate control records from larger outputs; the latter is implementation evidence, not a demonstrated live artifact-delivery flow.
- A deliberately bounded workflow prototype
- A separate intake prototype turns synthetic inquiries into missing-information checks and reviewable output. It uses deterministic rules and mocked model output. Default CSV export selects approved rows, but an explicit all-rows export also exists.
Decisions behind the interface.
Build the control layer around an existing runtime
Reusing OpenClaw makes its runtime and tool ecosystem available without claiming to build another agent engine. The product work sits around setup, access, state, and recovery, while remaining dependent on upstream runtime behaviour.
Protected access adds operational dependencies
Scoped launch tickets and resource-generation checks provide a clearer access boundary than a public server link. The cost is that session, tunnel, gate, and heartbeat failures all need understandable handling.
Separate a repeatable prototype from a live promise
Synthetic input and deterministic rules make the intake example inexpensive to reproduce. They do not establish that arbitrary tasks, real model calls, customer approval, and external delivery form a complete production workflow.
Where it stands.
Public product and pilot pages were inspected in the October 2026 review. Selected setup, access-policy, recovery, and synthetic intake logic passed isolated local checks; this is not evidence of a real customer task, paid provisioning, or a 24/7 service guarantee.
Available to explore
- Public OpenClaw setup and product overview
- Public use-case examples and security information
- Pilot information, with new signup and application entry currently closed
Still evolving
New registrations and pilot applications were closed in the review. A broader business workbench remains in development. Hosted provisioning, paid operations, real model execution, and customer workspaces are not demonstrated as verified public workflows here.
Future direction
Move from a managed runtime toward narrowly scoped, reviewable tasks with inspectable outputs and clear human approval boundaries.
Why I keep building it.
Supporting production systems made me care about what happens after a create request: ownership, readiness, timeouts, recovery, and a clear handoff. Claw2Agent is where I apply those concerns to a personal full-stack product.
This is my personal product, separate from my professional banking-support work.