Most teams still treat a coding agent like a one-shot chat window: open a terminal, start a cold process, pay the full context tax, then throw the session away. We wanted something closer to how we already run production infrastructure — a long-lived service you can call from schedules, scripts, and (soon) any browser on the LAN.
This week we wired that pattern into our own stack: a durable coding agent process, a thin ACP (Agent Client Protocol) client, and the first hooks so myawx scheduled work can talk to the same agent instead of cold-starting Grok every time.
Why a long session beats a cold start
When you launch a full agent binary for every job, you pay repeatedly for configuration, tool wiring, and the early turns that only re-establish session continuity. For interactive engineering that is annoying. For automation it is wasteful: higher token cost, slower jobs, and less chance to keep a useful prompt cache warm across related tasks.
A long session model flips the default. Keep one agent process running where the work already lives — next to deploy tooling, Git, and our internal control plane — and let short-lived clients attach, send a prompt, stream a result, and disconnect. The heavy process stays up; the clients stay thin.
ACP: a proper client protocol, not another chat silo
We standardised on the open Agent Client Protocol (ACP): JSON-RPC sessions over a WebSocket (or stdio in an editor). That is the same family of idea as language servers — a clear client/agent boundary — rather than a proprietary UI locked to one vendor surface.
On our side that means:
- A long-lived Grok Build agent service (systemd), always-on for automation.
- A small open acp CLI (stdlib Python) for shells, cron, and jobs: connect, prompt, print, exit.
- Experiments with desktop ACP UIs for interactive use — useful for a quick look, but not the spine of operations.
We also cloned and studied the public Grok / Grok Build source where it is published under open terms. That transparency matters for AI engineering on infrastructure we operate ourselves: we can see how serve mode, sessions, and tools are meant to fit together instead of guessing from a black box.
myawx schedules that already call Grok
Our internal orchestrator — myawx — already fires recurring work: mirror maintenance, mail-driven tasks, incident follow-ups, content desk batches, and other fleet chores. Some of those schedules already hand a brief to Grok when a human would otherwise paste the same checklist into a terminal.
Until now many of those paths cold-started a full agent for each run. We are moving them onto the long-lived agent via the ACP CLI so a scheduled job is “send this brief to the running agent” rather than “boot the universe, then ask one question.” That keeps session continuity where it helps, cuts redundant startup, and makes the automation path look like the interactive one.
Not every job needs a model. Bulk desired-state work still belongs in Ansible and deterministic pipelines. Where judgment, multi-step host-local investigation, or natural-language briefs help, the agent is now a first-class callee of the scheduler — not a side hobby in a developer’s laptop session.
What we are not doing (yet)
We are not replacing GitLab, OTAP, or change control with chat. Public managed hosting and customer isolation still run on the same boring rules: inventory, reviews, and production gates. The agent sits beside that machinery; it does not dissolve it.
We are also careful about exposure. ACP over plain WebSocket is a protocol, not free encryption. Inside a trusted private network with authentication it is a pragmatic ops surface. On the open internet it would need TLS and stricter policy — the same common sense we apply to any admin API.
Next: an HTTP ↔ ACP gateway for every LAN browser
The CLI is enough for myawx and operators who live in a shell. The natural next step is a small HTTP ↔ ACP gateway: a local web front end that speaks ordinary HTTPS to browsers on the LAN and ACP to the agent behind it. No special desktop app required — any browser on the private network could open a session, pick a working directory, and drive the same long-lived agent the schedules use.
That gateway is planned work, not a product launch. When it lands, interactive and automated entry points share one agent, one audit story, and one place to reason about cost (cache hit-rate, context growth, and when to start a fresh session versus continue a long one).
How this fits 3DN
3DN is a family of products and infrastructure under one roof: compute and managed hosting, plus work · money · politics surfaces such as DutchBud, PolitiCap, and ZZP2ZZP. Coding agents are not a side demo for us; they are part of how we operate production systems with fewer brittle hand-offs.
Digital sovereignty here is practical: run the agent where your tools and policies already are, keep the protocol open enough to swap clients, and refuse to pour every automation into a closed SaaS chat that cannot see your fleet.
In short
- Long-lived Grok agent service for ops and automation.
- Thin ACP CLI for scripts and myawx-related schedules that already call Grok.
- Open Grok Build source used as a map, not only a binary drop.
- Roadmap: HTTP ↔ ACP gateway so any LAN browser can reach the same agent.
If you run your own agents on your own metal, the interesting question is no longer “which model?” alone — it is “which process stays up, who is allowed to call it, and how cheap is the next prompt when the cache is already warm?”
Leave a Reply