Bold.org's internal agent runs on read-only credentials to five company systems

The boundary is at the credential. The author wrote that "Rather than relying on the model to be smart about when a change is safe, I did not give it permissions to write to remote systems in the first place." ^[6] Access is gated behind Google sign-in for the company domain, and all of the agent's remote access is read-only ^[5]. For anyone copying the design, the review question is what the read scope returns.

That scope grew one wrapper at a time. In January, MCP was still emerging and many of the systems Bold.org needed had no useful server, so the author closed the gap with small CLI tools, mostly thin wrappers around OpenAPI endpoints or existing SDKs, exposing only the operations the workflows needed ^[11]. He wrote that they were "intentionally boring: structured results, narrow permissions, proper error handling, and credentials kept away from the model" ^[12]. Per-operation wrappers cost more up front than pointing a general-purpose server at a system. They are also reviewable: you can read the operation list before you issue the token.

One pair of statements needs reconciling before reuse. The post says every remote integration is read-only ^[5], and also that the agent automates parts of dashboard setup and analysis in PostHog and Grafana without engineering stepping in ^[9]. Creating a dashboard is a write. Either those two wrappers hold something more than a read credential, or "dashboard setup" means producing config that a human applies.

The operational number is a claim about Bold.org's workflows. For the workflows they target, investigations that previously took multiple hours and required finding the right access through three or four people can usually be completed in zero to one hour ^[7]. That transfers only where your backend events are already structured and queryable, the way Bold.org's were in ClickHouse before the agent existed ^[1]. Where the delay was access and context. And where the read credentials your wrappers hold reach the same systems the humans would otherwise have opened.

Distribution came from the shared channel. Someone asks a question in Slack, the agent investigates it, and ten other people see both the result and the way the question was asked ^[14]. The author says that mattered more than any launch document ^[13], and that Slack and Linear meant nobody had to adopt a new destination or remember that an internal web application existed ^[15]. The web interface stayed useful for private or longer work ^[16].

The system consumes billions of tokens per month. The author reads that as a reason usage analytics and cost awareness matter, and as a signal that the tool is part of how people work ^[10].

The post is framed as five things that worked and five the author would approach differently ^[17]; the text available breaks off inside the second of the five that worked. He wrote: "I also spent time solving problems I did not really have, left some important problems too late, and assumed things were obvious when they definitely were not." ^[20]