My Agent Experience

A personal agent you deploy into your own Cloudflare account. It holds durable conversations, runs code across your workspace and connected machine, schedules recurring work, delegates bounded analysis, and surfaces what needs you — all behind your Access login, on infrastructure you own.

In this 3.4s clip the agent writes a workspace file, runs a command on a connected machine, and reads a remote agent run — one configured path, not a validation of every boundary. (The clip was recorded when the third connector slot was Cloudbox; that slot is now Terrarium — same shape, bounded cloud runs with verified receipts.) Open the MP4.

My AX is experimental and single-operator: you control the deployment and its Cloudflare resources. Calls to model providers, MCP servers, Terrarium, and a connected machine run outside My AX's storage boundary — each receives only what you send it and retains data under its own policy.

Read this in seven minutes: What It Does (capabilities) · Important Limits (the hard bounds) · Deploy (get it running) · Repository Map (where the code lives).

Verify before trusting. npm run check covers local build/type/tests only. Access, containers, models, voice, push, and workspace restoration are proven only by the deployment proof, not by a green local run.

What It Does

• Check-in — authenticated HTTP and MCP surfaces summarize what needs the owner, what is running, what recently completed, and the next steer from existing Attention, jobs, and run receipts. The shell maps raw API steers to rendered owner destinations for /attention, /runs, and /jobs.
• Durable conversations — Think is authoritative for conversation execution and retained message state. D1 contains a derived transcript index for UI, search, and export. In-flight work may still be interrupted by provider or runtime failure.
• Connected capabilities — the model and generated programs receive callable tools instead of OAuth tokens or deployment secrets. Trusted server-side adapters hold credentials and retain their configured authority.
• Execution environments — use the container-backed owner workspace plus optional Machine, Terrarium (bounded cloud agent runs with verified receipts), and public-page Browser capabilities.
• Live UI control (page connector) — while a chat tab is open, the agent can drive the owner's own browser session: list/switch conversations, read health and the transcript tail, open Settings/Attention/Sessions, notify, and navigate. Interactive artifacts it creates with create_svelte_artifact can self-register scoped tools the agent then invokes (page.listArtifactTools / page.invokeArtifactTool), parent-mediated and arg-validated — a live instrument built once and steered later.
• Recurring jobs — authenticated UI routes and agent tools share one owner-scoped service to create, update, pause, resume, run, inspect, and delete scheduled prompts.
• Bounded delegation — a parent can invoke up to two concurrent child agents for model-only analysis, then synthesize their retained results.
• Attention and outputs — decisions and supported output records remain associated with their owner and source conversation; object bytes live in R2 where applicable.
• Saved recipe learning loop — you approve a successful work_code run as a named recipe, then reuse it by name instead of re-deriving the logic. Reuse runs the exact saved code (no regeneration drift). It trades re-derivation for a determinism gain, not a guaranteed token saving: reuse cuts output tokens but total tokens only fall for large or repeated procedures, so a one-line recipe can cost more end to end. Per-cycle model usage is measured live in production via cycle_costs and the owner-scoped /api/cost-series.

Owner through Cloudflare Access
              │
              ▼
       MyAgent · Think
 authoritative conversation
   execution and history
              │
    ┌─────────┼───────────┬──────────────┐
    ▼         ▼           ▼              ▼
 tools/MCP  recurring   delegation    decisions/outputs
              jobs      (max 2)       Attention + push
    │
    ├─ workspace.*  My AX Workspace
    ├─ machine.*    My Machine
    ├─ terrarium.*  Terrarium (bounded cloud agent runs)
    ├─ page.*       live browser UI + self-registering artifacts
    └─ browser      public-page Browser Run

Who owns what

Think is authoritative for conversation execution and history. D1 stores application records and derived indexes; R2 stores object bytes and workspace snapshots. Snapshots are not continuous backups.

Code Mode has no direct database, secret, or network bindings. Its allowlisted server-side callbacks retain their normal authority.

Check-in as the owner-return dashboard

GET /api/check-in and MCP my_ax_check_in remain the stable machine-readable receipts. They return raw API steers such as /api/attention, /api/runs?status=failed, and /api/jobs?status=active so agents and API clients can keep using receipt endpoints directly.

The authenticated shell renders those steers as owner-friendly destinations:

• /attention — unread Attention context by kind and session, exact view totals, safe next actions, empty-state receipts, stable data-attention-api-receipt-href / data-attention-source-href link metadata, and a same-origin data-attention-seen-form to mark the current filtered view seen.
• /runs — run status summaries for open, running, completed, failed, and aborted work, with data-runs-api-receipt-href, data-run-receipt-href, and data-run-events-receipt-href receipt metadata.
• /jobs — recurring job status summaries for active and paused jobs, with data-jobs-api-receipt-href and data-job-history-receipt-href receipt metadata.

Those rendered pages are Access-protected, preserve the raw API receipts, and should answer the return-loop questions: what needs me, what is running, what finished or failed, where can I safely steer next? In the shell, Check-in bucket links navigate to rendered owner destinations while carrying the authoritative raw receipt href in data-check-in-raw-href for proof and debugging.

Important Limits

Feature Status and Limits is the current-state inventory: what is real, where it lives, and the known limits.

Deploy

Requirements:

• Node.js 22 and npm 11
• Docker with Colima, Docker Desktop, or WSL2; native Windows shells are not tested
• Python 3, Bash, and OpenSSL
• A Cloudflare account authorized to create Workers, Containers, D1, KV, R2, Workers AI, Browser Rendering, and Dynamic Worker Loader resources; paid usage or product enablement may apply

setup.sh deploys infrastructure, but does not produce a production-ready or verified service. Review Deploying My AX before running it against an existing account or exposing the hostname.

git clone https://github.com/acoyfellow/my-ax
cd my-ax
npm ci
npx wrangler login
npx wrangler whoami
# If more than one account is listed:
export MY_AX_ACCOUNT_ID=your_target_account_id
bash scripts/setup.sh

The script creates missing named resources, binds configured existing resources, generates absent bridge/encryption secrets, applies pending remote D1 migrations, and deploys. On a fresh Worker it replaces the repository's historical Durable Object migration chain with one current baseline; existing deployments retain their append-only history. When the expected secret source remains available, rerunning setup reuses keys rather than rotating them; it cannot recover deleted keys. Pin MY_AX_ACCOUNT_ID whenever Wrangler exposes multiple accounts.

Before sending a real turn:

1. Put the hostname behind a Cloudflare Access self-hosted application.
2. Set CF_ACCESS_ISS, CF_ACCESS_AUD, BRIDGE_BASE_URL, and CLOUDFLARE_ACCOUNT_ID as described in the deployment guide.
3. Add bucket-scoped R2_ACCESS_KEY_ID and R2_SECRET_ACCESS_KEY to make workspace snapshots survive container replacement. Without them, treat workspace files as disposable.
4. Confirm the default Workers AI model is available to the account; configure gateway-backed routes only if you intend to expose them.
5. Redeploy, verify anonymous access is rejected, and verify authenticated /api/health returns ok: true.
6. Open BRIDGE_BASE_URL through Access and complete one model turn. Health proves routing and bindings only; when workspace persistence matters, also run the documented snapshot/restore proof.

Push additionally needs VAPID secrets. Managed OAuth callbacks require an Access-gated HTTPS hostname; loopback cannot complete that flow. Deploying My AX contains copy/paste configuration, verification, troubleshooting, and guidance for private deployment wrappers. Each installation must own separate Worker, D1, KV, R2, Durable Object, Access, and secret state; multiple installations may share a source revision but must never share runtime resources.

npm run check builds generated assets, typechecks, and runs local tests. It does not prove Access, containers, models, voice, push, or workspace restoration. Use the deployment proof for deployed checks.

Connect Tools

Open Settings → Connectors → Add and enter an HTTPS MCP endpoint reachable from the Worker and allowed by the destination policy. For supported OAuth-enabled servers, My AX attempts metadata discovery and stores grants encrypted with owner-bound context under the deployment-wide MASTER_KEY. Incompatible metadata or callback configuration will not connect. Replacing the key without retaining the old value permanently prevents decryption of existing grants.

Connector URLs are screened for embedded credentials and disallowed literal destinations. The operator allowlists exact MCP method identifiers for Code Mode; My AX does not prove that an allowlisted method is side-effect-free.

Optional providers:

• My Machine — run machinectl. This grants terminal-equivalent access as the companion's OS user; use a dedicated least-privilege account.
• Terrarium — configure TERRARIUM_URL and a dedicated TERRARIUM_CONTROL_TOKEN shared only by this My AX deployment and its Terrarium service. The agent spawns bounded cloud runs and reads back verified receipts.
• Web Push — configure VAPID and grant browser notification permission.
• Pantry bridge — set PANTRY_TOKEN (and optionally PANTRY_URL, default https://pantry.coey.dev) to push enabled saved recipes to a pantry for reuse by other agents. Additive, enabled-only, fail-soft, and a no-op without the token. See Deploying My AX.

Repository Map

For contributors, the main entry points are:

src/agent.ts          canonical Think agent and tool assembly
src/user-agent.ts     owner root and conversation facets
src/check-in.ts       owner-scoped check-in read model
src/jobs.ts           native recurring schedules
src/job-service.ts    owner-scoped job CRUD and evidence
src/recurring-job-run.ts shared job terminal state and owner receipts
src/saved-recipes.ts  owner-approved reusable work_code recipes
src/delegate-many.ts  bounded Agents-as-tools delegation
src/work-tools.ts     Workspace, Machine, Terrarium, Page, and codemode catalog
src/terrarium-tools.ts bounded cloud agent runs with verified receipts
proof/svelte/page-registry.ts  live-UI page connector verbs
proof/svelte/artifact-tools.ts artifact self-registration registry
src/mcp-code-mode.ts  allowlisted MCP composition
src/routes/           authenticated HTTP adapters
proof/svelte/         product UI and allowlisted result widgets
migrations/           D1 application and projection schemas

State ownership and request flows are in Architecture.

Development

npm ci
npm run check
npm run dev

Local Development documents loopback mode and the Access-gated tunnel needed for OAuth callbacks.

Documentation

• Architecture
• Feature Status and Limits
• Deploying My AX
• Deployment Proof
• Security Policy
• Contributing
• Changelog

Bugs and feature requests belong in GitHub Issues. Report vulnerabilities through the Security Policy, not a public issue.

License

MIT