Six months of building Voxdale's company brain

In January, Voxdale’s operating model lived where most companies keep it. In people’s heads, in shared drives, in Confluence spaces. Instead of an ERP, there were over forty point solutions, each of which solved a single problem: time tracking, sourcing, contract management, etc.

None of that is unusual for a mid-sized firm. Companies form functional groups as they grow, and these departments solve their own problems, one sensible purchase at a time. Sales bought a CRM in year two. Operations picked a project tool in year three. Finance had to force-adopt a new tool because its US-based invoicing tool had missed the EU’s Peppol compliance memo. Every one of those decisions was the optimal choice on the day it was made. But the result is the same client exists in six systems in six slightly different versions.

For thirty years, building a small piece of internal software was expensive. A form that fed a database and sent a few emails was a project. Compared with what we can do now, our software production capabilities were caveman level. So companies did the rational thing and did not build. Point solution tools accumulated, and people shuffle data from one system to another.

Two things have changed. Documentation now pays back the moment it exists, because an agent can hold all of it at once and read it in seconds. And building small internal software has gone from a project to an afternoon.

Voxdale’s CEO saw the same trend and took the opportunity to prune what a decade had accumulated. What follows is an honest accounting from inside a mid-sized professional services firm.

The order matters more than any tool choice in this piece. We did not start by connecting AI to the existing systems. We started by writing down how the company works, in one place, and only then began plugging the systems in one at a time.

That place is voxdale-os: the operating model as plain text. How projects run, what the policies are, what was decided and why, a curated entry per client. Text, because a model reads text natively and a person can still read it in ten years.

The substrate is GitHub. That looks like an odd choice for a hardware company, but it was deliberate. A git repository gives you a few things a wiki cannot:

• every change carries an author and a reason
• nothing lands without review
• the whole history is queryable, traceable and reversible
• it can host code as well as natural language (in fact code is what it was made for initially)

Voxdale already ran on Atlassian, so Bitbucket was the cheaper option. We chose GitHub anyway, because the team had lost patience with Confluence and Jira, and Rovo - Atlassian’s attempt at AI - had not changed their minds.

At first, people had to clone a repo. This went about as you would expect: two people actually did it, but it helped us identify the AI champions. We promptly (har har) fixed the distribution problem by packaging the operating model into a plugin and getting Claude For Teams licenses for everybody.

The operating model since reaches every colleague as a plugin, bundled inside their preferred interface. The voxdale-os data is automatically refreshed whenever a reviewed change lands - no git pull needed. Reading it is built in. Changing it is not: proposals arrive through the repository, a named owner approves them, and only then do they count. That asymmetry is by design: everyone reads the current version; one owner per domain guards the gate.

Then the question becomes what belongs in it. A document goes in when four things hold at once:

• it will likely still be true in a few months,
• any colleague may read it,
• it is mostly text or code (although it also handles other files)
• someone has checked it.

Everything else stays in Drive. The car policy goes in the operating model; this week’s test data does not.

With the brain in place, you start connecting the tools people actually use. Google Workspace came first, because that is the software every employee uses daily.

Perhaps the biggest change relates to project knowledge. At Voxdale it sat in two places, Google Drive and Confluence, and the line between what belonged in which had blurred over the years. So every search ran twice. You looked in Drive, found nothing conclusive, looked in Confluence, and were left deciding which of two half-answers was current. Nobody trusts a system that makes them do that.

In Q2 we decided to sunset Confluence. Dozens of client-project spaces and thousands of pages and attachments were migrated into the project drive each team already shared with its client. A single overnight run moved the data to its new home. The whole migration, including the design decisions and the verification, took eight days. Product designers and engineers checked every move item by item.

Not long ago a migration of this scale would have taken a quarter rather than eight days. Companies can move faster now, provided they use the tools properly. Three things made the difference.

AI did not migrate the data. AI helped write the deterministic software that migrated the data. Voxdale’s work includes mission-critical calculations and simulations. Details matter, and the company cannot afford a migration agent to hallucinate or garble a single byte. An agent wrote and debugged the scripts; the scripts did the moving, the same way every time, with a checkpoint after each step so any run could resume where it stopped.

Agents get useful the moment a company can say what lives where. With Drive piped into the company’s Claude Code plugin, the reaction to what the agent returned went from “can I trust this?” to “I didn’t know we could do that.” Project managers, designers and engineers all got the same thing from it: answers drawn from the actual project record rather than from memory. Project managers in particular now catch changes to agreed scope earlier, because the agreed scope and the current state are readable side by side.

The migration laid the foundation for an agentic architecture. Next to each project’s documents we wrote a short entry in voxdale-os: what the project was, who it was for, what got decided, and a pointer to the folder. That unlocks the next phase, a long-lived agent per client that maintains the documentation, watches the project constraints, and eventually tracks customer success.

Agents do not touch the engineering. They do nothing useful (yet) with CAD geometry, and nothing at all with the judgment that turns a concept into something a factory can make. That stays the engineer’s craft. They do make the documentation load around it easier, and that is where a lot of the hours had been going.

Voxdale’s software register lists dozens of sanctioned and trial tools across eight functional areas. Most are decent tools, but they were not designed for a world with agentic software. Nor do they talk to each other out of the box. Where they connect, the connection is often a person re-entering data from one into another.

Wiring two systems together used to cost more than paying someone to retype between them. This is no longer the case. So the people inside the processes started building the fixes themselves.

/submit-expenses

Expenses went from paper sitting on someone’s desk to a system with automatic routing and OCR in less than a month. The system was vibe-coded by the office manager (recently hired precisely because of his AI ambitions) and reviewed by Machinegeist’s software architect.

/write-proposal

A proposal used to start life as a copy of the last proposal, which is how last quarter’s scope and a stale rate card end up in front of a new client. Now it starts from a command. The agent asks the questions about what the prospect needs, then reads Voxdale’s positioning, the commercial policy and the brand voice out of the operating model, and produces both a draft and the branded document that goes out. This takes less than an hour, where it used to be an afternoon or more. The guardrails are written into the procedure: it never sends anything without human approval, and a rate outside the agreed band or a fixed price stops and asks for approval instead from sales leadership.

/my-car

Voxdale has no dedicated fleet manager or fleet software but with around 30 cars, questions arrive each week: lease ends, insurance cover, tire swaps, charging, what to do about a cracked windscreen. We codified the car policy, tied it to the Belgian mobility-budget scheme, and built an agent that answers for one specific car. It takes a number plate as its argument, which sounds like a small thing and is not: plates work for pool cars and shared cars, where looking a person up breaks, and they need no identity resolution at all.

One thing holds true for all these agents: the build itself is roughly twenty per cent plumbing and eighty per cent policy content that had to exist first. Agents are useless if your company is confused about its own policies.

Two rules of thumb before you start building:

It has to beat the old process end to end. Moving the bottleneck to another part of the process doesn’t improve the company’s productivity.

The person inside the process designs it; a forward deployed engineer reviews it. Domain knowledge decides what the thing should do. The review decides whether it should exist, which is a different question and the subject of the next chapter.

Letting colleagues build software is only a good idea if you include guardrails. This is the same principle as with voxdale-os: anything that changes the operating model arrives as a proposal, a named owner reviews it, and only then does it ship.

One over-zealous contributor spent a weekend building a replacement for DocuSign. It worked, in the sense that it collected signatures. The reviewer turned it down anyway, because a signature tool is not a form that collects signatures: it is an audit trail that has to hold up years later, when somebody disputes what was signed and when.

Surprisingly, the weekend work paid off. Working through why the build was refused surfaced the fact that Google Workspace already includes e-signature, which covers what Voxdale actually needs and retires a subscription.

Two other guardrails are important:

• The agent reads whatever the person in front of it can read, through that person’s own Google account and their own permissions, so nothing widens anyone’s access.
• The agent writes nothing back into Drive. An AI system that iterates on live files leaves a trail of near-identical copies and no clear moment where a person took responsibility.

The prediction most people get wrong is that adoption is a training problem. Run the sessions, hand out the licences, wait.

What actually moved it at Voxdale was putting AI capability into the career development framework and into hiring. Voxdale doesn’t hire anyone without a deep-dive on their willingness to adopt AI. And agentic prowess is now an integral part of any career conversation.

Once working this way is part of what growth means, and part of what a candidate is assessed on, it stops being an initiative and becomes part of the job.

Finally, we learned to meet people where they are. A power user and a colleague opening Claude for the first time need different things, and handing both the same training deck serves neither. So we drew the map instead, the one at the top of this piece: which mode does what, when to reach for it, and what most people miss. A longer version, one page per mode, hangs in the office.

The AI roadmap is always evolving and some things are mid-build. Showing only the finished work would misrepresent how any of this happens.

Meeting capture. The company now records and transcribes its meetings, which was an immediate improvement over the previous state, where notes existed if someone happened to take them. The step that is still missing is routing: a transcript is only worth what it feeds, and the destination for that material depends on work that lands this autumn.

The finance stack. The finance and operations stack is moving to a new ERP, picked for being the most AI-forward of the SME options, and AI is compressing that migration in the same way it compressed the Confluence one: the work that used to be a consultant reading and re-keying is now largely a matter of pointing something at the source.

For anyone weighing this against their own company:

Sequence beats tooling. The brain first, because everything downstream reads from it. Then the tools, one at a time, starting with wherever the work already happens. Then small automations by the people inside the processes. Then the structures that decide whether any of it counts. Run that order backwards and you get impressive demos on top of a knowledge base nobody trusts.

Meet the knowledge where it lives. We merged Confluence into Drive because Drive was where the work already happened and because agents could easily reach it. The instinct to build one new canonical repository and mirror everything into it is a pitfall.

Keep the agent out of the deterministic path. An agent wrote the migration scripts. The scripts moved the data. Don’t let agents do what traditional software does best.

Most of an agent is content you have not written yet. These came out at roughly twenty per cent plumbing and eighty per cent policy. Expect that ratio, and use the build to find the gaps: the questions an agent cannot answer are the ones nobody had written down.

Put permissions where they are enforced. An agent running under a person’s own identity can read whatever that person can read, so an instruction telling it not to is decoration. The access rule belongs in the platform, not the prompt.

One gate, and it is about knowledge, not code. The reviewer’s value is knowing what already exists, in the platform and in the company. That is why review cannot be delegated to the thing doing the building.

Verify the synthesis, and budget for it. Drafting the project entries from the migrated documents produced errors an adversarial check had to catch, confabulations among them. Skip that step and you undermine all trust in the project.

What compounds across two quarters is the pace. The company now ships internal change at machine speed.