Bring Your Own Bot

What I learned building Klau

After building the bot that is embedded in Klau and seeing how people used it, I've come to understand something about where AI in the enterprise is headed. Every person who uses my software is going to have their own AI agent that is better than what I've added into the app, and they'll want to use that instead. Some will use Claude. Some will use ChatGPT or Grok. Some will use whatever comes next. I don't get to pick, and users will be happier if I don't try.

So my job is not to build one more chatbot into Klau or Strata (if this is the first time you've seen that name, it's a code name for a product under development). My job is to make it easy for the agent a person already uses. It's BYOB for work: "bring your own bot."

What 37signals did

Then I read how the team at 37signals approached this with Basecamp. It seems obvious in hindsight, and I plan to follow their lead.

They tried built-in AI inside Basecamp. They decided it was not good enough to ship. On March 25, 2026, they published Basecamp as a tool for agents instead.

They gave agents three ways in, and all three follow one rule: the agent can do what that person can do, and nothing more.

• An agent in a terminal. The basecamp command line tool works with any agent that can run a shell. The user signs in through a browser, and the agent drives Basecamp by running commands. A short guide teaches the agent the domain rules, such as how to read a Basecamp link before guessing an id.
• An agent in a chat app. ChatGPT, Claude, Cursor and Grok connect to one hosted address. The user signs in and picks read-only or full access. Nothing to install. Disconnect it, and the agent is cut off.
• A bot that lives in the room. A chat bot in Campfire has its own identity. An admin creates it, people mention it, and it posts as itself, not as the person who asked.

The part I want most is the contract they put on every command:

• A success returns the data, a short summary, and the next commands the agent can run, filled in with real ids. The agent chains work without guessing.
• A failure returns a stable error code, a hint, and whether to retry. The agent can decide what to do without reading prose.
• An agent can ask one command what it accepts. It does not load a list of 155 endpoints into its prompt.
• The same command serves a person at a keyboard and an agent in a pipe. Readable text on a screen, JSON when piped.
• The command surface is checked on every build. Removing a flag is a breaking change.

DHH's reason for a command line tool instead of an agent that clicks through the screen is speed. A screen-driving agent has to take a screenshot, read it, and click. An agent that runs a command gets a structured answer in one step, reads the next valid command, and tries again. That fast loop is what makes an agent useful.

I don't see many people building for this yet. Most software adds an AI button and asks you to use their assistant. I want the opposite. Your agent, your choice, and my software works with it.

What this means for Klau and Strata

Klau is a teammate for roll-off haulers. Strata runs at a hauler with a landfill, three transfer stations, and about 100 trucks. The people who use them are owners, CSRs, dispatchers, scale house staff, and managers. Each of them will bring an agent sooner or later. Here is how my software will meet them.

The same contract on every capability. Each result names the next valid action. Each error is data with a code and a hint. An agent can ask any one capability what it accepts.

Sign in from a chat app. A user connects Claude or ChatGPT, signs in, and picks what the agent may do. In Klau, the agent can ask how a dispatched day scored and where time was lost. In Strata, it can look up an account, check a service day, or draft a work order. Either way, it has the same access that person has.

A command line tool for operators. An operator's coding agent can do the same work from a terminal: pull reports, check scale tickets, or fix a batch of records.

Named assistants that post as themselves. Some tasks belong to a bot with its own identity, such as a dispatch assistant in a team channel. That is a separate grant from "act as this person," and I will keep the two apart.

Where I will go further

Two limits in Basecamp's approach are fine for a project tool but not for a hauler's operations.

First, Basecamp's access is the person's project membership. Read-only is enforced by the connector, not by the underlying sign-in. That is acceptable for to-dos. It is the wrong ceiling for payments, credits, and price changes. In Strata, sensitive actions will need their own grant, checked on the server, no matter which agent asks.

Second, Basecamp's room bots trust a secret link and do not sign their requests. A bot in my software that can change anything will check who is calling.

Why this matters

I want to help shape where software for this industry goes. I think the answer is not one vendor's assistant. It is software that gives clear, safe answers to whatever agent the user picks, so the user gets the tool they like and the work gets done right.