At BirdDog, we help landowners make decisions about their property. That work spans soil fertility assessments, insurance, land sales, and lending. The products are different, but much of the work behind them is familiar: understanding a customer’s situation, gathering information, preparing documents, and making sure the next step happens.
We’re a small team, and a surprising amount of that work used to involve moving information between systems. The information often existed somewhere already. Someone still had to find it, work out whether it was current, and put it where the next person needed it.
I started building Bolt to bring that work into one place. It’s now our internal workspace, with messaging, documents, calls, and an agent connected to the systems we use. The team works with it through a web app and native apps on iPhone and Mac. I build it with a coding agent, while using it in the business myself.
The early work was connecting the agent to useful information. As it took on more responsibility, I spent more time on what surrounds the model: how it gets permission, remembers a decision, checks an answer, and tells someone when it couldn’t finish. Those details now account for much of the product.
What does a day with Bolt look like?
The most useful changes show up in work people already had to do. We haven’t asked the team to become experts in prompting or to manage a collection of agents. They can ask Bolt for help in the same workspace where they talk to each other.
- Preparing for the day. The morning brief brings together the calendar, inbox, outstanding decisions, and work the company is tracking. It runs as an agent task, with access to current information, so the result can explain what needs attention. People start with that context instead of assembling it themselves.
- Preparing an application. An insurance carrier’s PDF can contain hundreds of fields. Bolt fills what it can from the customer record and provides a review of what it completed and what it couldn’t find. Missing information stays missing. The person reviewing the application can concentrate on those gaps and the substance of the answers.
- Understanding the business. A question about leads, ownership, or progress can be answered in the thread. Aggregates are computed over the full relevant record before the model explains them. That distinction matters: displaying a short table is fine, but calculating a company total from that table is not.
- Following through. Bolt recognizes ongoing work from conversations and keeps track of it between sessions. Someone can return to a discussion after time away without reconstructing the whole history. When the next step involves an external action, such as sending an email or uploading a document, Bolt presents it for approval in the thread.
That gives people more room for the work that depends on their experience: talking to a customer, reviewing an application, or deciding how to move something forward. The preparation still happens, but it no longer has to occupy the same part of their day.
Why build the harness ourselves?
We explored managed agent platforms and built on one for a while. That was useful work. It helped us understand which parts of the experience we needed to control as Bolt became more involved in daily operations.
By harness, I mean the software that manages an agent’s execution: supplying context, running tools, applying permissions, recording results, and returning control to the person using it. Our reasons for owning that layer came down to a few practical requirements.
- Actions needed consistent rules. An action should go through the same checks whether a person clicks a button or the agent requests it. We wanted approvals, execution, and the resulting record to be part of one implementation that we could inspect and change together.
- We needed to investigate the whole run. When an answer is wrong, the final message rarely explains why. We keep the tool calls, results, and checks in our database so we can reconstruct what the agent actually saw and did. That lets us distinguish a failed read from missing data, or an execution failure from a misleading reply.
- We wanted to evaluate models in our own system. A model can write an excellent response and still fail to save something it was asked to remember. We keep the model behind an adapter and evaluate candidates against real workflows, including the resulting database state. That has also let us respond when a provider’s performance changed without rebuilding the product around another API.
Ramp’s write-up on building Laminar describes similar priorities around model choice, observability, and a close relationship between the platform and the people building on it. Their platform serves a much broader set of products. Our scope is narrower: one workspace, shaped around how our company operates.
Working with a coding agent made that scope feasible for me. I can investigate a problem, work through a change, and try it in the application while the original problem is still fresh. I’m also responsible for maintaining what we build. Owning the harness made sense because these decisions were becoming part of my daily work anyway.
What’s in the machine?
Bolt runs on a rented server with Postgres. Its connections include Google Workspace, our CRM data, QuickBooks, HubSpot, and Meta Ads. The web and native clients share the server’s action executor, so we can apply policy in one place.
Each action that touches an external system declares the capability it needs. Policy allows it, requires approval, or denies it. An approval request appears as a card in the conversation. After the person decides, the outcome becomes part of the conversation record.
That last step took an actual failure to get right. I approved a Drive upload and saw a brief confirmation toast. The upload happened, but the conversation never received a readable account of it. On the next run, Bolt offered to upload the same document again. We had updated the interface without updating the record the agent would read.
The fix was to write approval and denial outcomes into the thread in plain language. The human and the next agent run both need to know what was decided and what happened afterward. A successful operation with an incomplete receipt is still a product problem.
The completion check came from another fairly ordinary interaction. Bolt told me “Set —” after I asked for a reminder, but it hadn’t created one. The reply sounded exactly like a successful result. Nothing in the underlying system supported it.
We added a judge that reads the draft against the run’s tool ledger before the reply is sent. If a claimed action isn’t supported, the agent gets a correction pass. If the claim remains, the system replaces the draft with a failure message. This is a check on a specific class of error; it doesn’t make every answer correct. The judge is another model, so its behavior needs testing too.
Memory has its own rules. Bolt can save durable information during a conversation, and people can explicitly ask it to remember or forget something. Background passes consolidate that information and link memory entries to evidence from the transcript. Company knowledge follows a separate approval process: reported information is excluded from ordinary recall until an admin approves it. That boundary is enforced in SQL. Approved company documents also feed a standing primer so each run starts with context about the business.
These choices are closely connected. Memory is less useful if it preserves an unsupported claim. An approval is incomplete if the next run can’t see it. A well-written answer is still wrong if the data underneath it was only a partial read. Much of the engineering has been making those boundaries explicit.