Table of Contents
The Part I Kept Close
A few months ago I argued that AI had broken the build-vs-buy calculus, and that for a small team the default for internal tooling had flipped from “buy” to “build smart.” I closed that post by admitting I was holding something back regarding how we were using these internal tooling capabilities to build something that augments our engineering force at a deeper level.
This is me expanding to give a further peek behind the curtain.
What I held back wasn’t a single clever tool per se. It was the realization that the tools were never the point. I built a number of them, and I’ll describe them by function rather than by name (security and privacy are the whole job here, and I’m not going to hand anyone a map of our internal estate). But the thing worth writing about isn’t any one of them by itself. It’s what happened in the space between them, and what that space turned out to be good for.
Two things became true as we went down this path. First, the asset we’d actually built was the connective tissue no vendor sells you. Second, almost as a side effect, we’d built a business that AI agents can read and increasingly operate. I didn’t set out for the second one, at least initially. It fell out of doing the first one with discipline.
From a Pile of Tools to a System
I’ll start with what exists, described by what each does.
There’s a chain that runs our consulting business end to end. A scoping tool turns engagement parameters into a structured estimate: hours, fees, cost basis, margin. That estimate doesn’t get screenshotted into a deck and forgotten. It integrates with our CRM and submits directly into the engagement system, our internal ERP, where the opportunity moves through pursuit, contracting, delivery, and close. The engagement system, in turn, syncs active work into the time-tracking system, so the people delivering an engagement can log against it without anyone re-keying a project list. And the financial layer reads from that same engagement data, joins it to card spend, accounting, and payroll, and produces the P&L and the KPIs. At every stage, the understanding of what we deliver and our perspective on any given engagement archetype is tied to the same, consistent, malleable model.
Read that again as a single sentence - a scoping estimate becomes an engagement becomes a set of time codes becomes a line on the P&L, and a human re-enters the underlying facts exactly zero times. That’s one data spine with six distinct surfaces on it, not six products that happen to sit in the same browser.
There’s a second throughline around identity. One system provisions a new hire at the moment they join: Workspace account, repo access, password manager, the whole sequence, with the new person watching their own progress bar and acknowledging policy as they go. A second system governs that same access for the rest of its life: group membership, org-unit-to-group mapping, nesting rules, a lifecycle sync that reconciles drift on a schedule, all of it against a tamper-evident log. Provisioning and governance are the front and back half of one problem, and they share the same primitive underneath.
And there’s a third throughline that’s less obvious from the outside potentially: a knowledge layer. Human-authored content lives where humans already keep it, in docs, in presentations, in drives, in GitHub, in the intranet, etc. A middleware pipeline funnels that content into a single Git-native, Markdown-first brain whenever someone changes it at the source. A projection layer then fans that brain back out to every place an AI agent might need it, whether writing a document, designing a creative asset, researching a topic, or writing code. One human-maintained source of truth, many machine consumers, no one maintaining a second copy by hand. This is ultimately our way of modeling who and what Amastra is and becomes.
None of these three throughlines is exotic on its own. The point is that they interlock, and that the interlock is where the fun begins.
The Thing You Genuinely Cannot Buy
Here’s where build-vs-buy actually resolves, and it’s not where I expected when I wrote the first lines of code for an early version of an engagement scoping aid.
You can buy a perfectly good ERP. You can buy a perfectly good time tracker, a strong CRM, a competent IGA platform, an onboarding product, a finance suite. The market is full of mature, audited, battle-tested versions of each of these, and for many organizations buying every one of them is the correct call. I said this last time and I’ll say it again: please don’t go vibecode your own everything to save on license fees.
What you cannot buy is the seam between them that matches your business exactly. Vendors sell islands. Each one is well-built and entirely convinced it should be the center of your world. The integration story between any two of them is somebody’s afterthought, a n8n workflow, a nightly CSV, a “we have an API” that technically does and practically doesn’t. The shared domain model that would let an estimate and an engagement and a timesheet and a P&L all agree on what a “client” is and what a “project” is and who’s on the team simply isn’t for sale, because every vendor models those things in their own dialect and has no incentive to speak yours.
So when building got cheap, the highest-leverage thing to build turned out to be the causeways between the islands. The connective tissue, plus the single domain model running underneath it, is the part that’s bespoke to how Amastra actually works, and it’s the part that compounds. Every system we add to that spine gets more valuable because the spine is already there. That’s the opposite of the SaaS sprawl pattern, where every new tool is one more island and one more integration you’ll never quite finish.
The leverage is that we built one thing that happens to present ten faces rather than ten separate tools, and it can live in all of the places you already are and work.
Built On Boring, Identical Primitives
The causeways only work because everything underneath them is the same. This is the unglamorous heart of it, but it’s how the discipline pays off practically speaking.
Everything is persona-based and every surface authenticates the same way, against the same identity provider, gated to the same domain. It’s simply Workspace groups that tie back and curate the primitive that every other system already reads. When I add someone to a group, their access across the entire estate resolves correctly, because the entire estate was built to ask the same question of the same source.
Every system that touches a Google API does it through a least-privilege service account with narrowly scoped delegation, not through some over-permissioned god credential. Every system that mutates state writes to a tamper-evident audit log: who did what, to which thing, before and after. (I know, I know… shocker - Mitchell likes logs.) Every system ships behind a test gate, where a failing test aborts the deploy before anything reaches production, because I approached internal tooling the way you’d approach a security-critical system. Tests come first, not because it’s a best practice, though it is, but because it’s the only way to keep AI-generated code trustworthy at scale.
This is the least exciting paragraph in the post and it’s the most important one. The reason the system holds together is that I refused to let any single tool invent its own identity model, its own audit format, its own deployment story, or even its own design language. Consistency at the primitive layer is what turns a pile of apps into something with a single grain you can read across. (I’ll admit, when the cost to build and iterate is so low, the temptation to special-case “just this once” never fully goes away. The discipline is in saying no to yourself at 11pm.)
Coherence, not cleverness, is the key here.
Where AI Actually Lives In This
Now the actually interesting part… or two?
The first is the obvious one, and I covered the mechanics last time - AI helped build all of this. A single engineer with proper tooling, thoughtful approaches to the harness / control plane, structured documentation, and multi-model delegation shipped each production system that would have needed a small team a piece two years ago. That’s the leverage story and it’s honestly still surreal to be our new normal. But it’s not the interesting part anymore.
The interesting part is what that consistent substrate makes possible going forward, because when every system speaks via the same identity plane, exposes structured APIs, writes the same shaped audit trail, and documents itself in a machine-legible way, the entire estate is legible to an agent. The knowledge brain already projects firm context into every agentic surface we use, our coding agents, our IDEs, our research notebooks, our assistants, through a context server that filters what each consumer can see based on identity. One source of truth, many machine consumers, with access control inherited from the same primitive humans use.
What’s not fully built, and I want to be honest about the line, is the next step: agents that don’t just read the estate but act across it. The substrate for that is mostly in place and we’ve been experimenting on potential use cases. Every system already exposes structured interfaces, already gates on identity, already logs every mutation. An agent that scopes an engagement and builds a draft contract for review based on rough notes from a conversation wouldn’t need any new connective tissue. The prescriptive harness that acts as a control plane for those actions already exists, because that’s the human flow too. An agent would walk the same causeways we built for ourselves. We’re not running that end to end yet, but I can see the whole path from here, and the gap is execution and trust calibration, not architecture at this point.
Now how does this tie back to why I do this work at all? You do not let an agent operate your business unless the substrate has identity, least privilege, and a complete audit trail baked into every action. Most companies can’t safely point agents at their internal systems because those systems were never built to that standard. They have eleven half-integrated SaaS islands, inconsistent permissions, and no unified record of who changed what. We built the estate the way we build security systems, because security is the whole job. The surprise dividend is that a system safe enough to audit is a system safe enough to automate. The same property makes both true.
So again, the two angles really are just different sides of the same coin… The connective tissue you build because no vendor sells it is the exact same connective tissue an agent needs to operate. Build the business so it’s coherent enough to reason about, and you’ve built it coherent enough to delegate.
What I’d Tell You To Do With This
If you’re earlier in this build-out of an “agentic renaissance” than we are, the temptation is to read “build the connective tissue” as “build everything,” and that’s the wrong lesson. Tokenmaxxing, seeing who can write the most SKILL.MD files the fastest, and racing to be the most performative won’t get you anywhere. (Other than in trouble with your CFO maybe according to recent WSJ articles…?) The lesson is narrower and more useful in my humble opinion.
Design and pick the data spine that actually defines your business, the one sequence of facts that flows through everything else. For us it’s the engagement itself and the permutations it can take, from estimate to P&L. For you it might be a patient, a deal, a shipment, a case. Build that model once, deliberately, and make every surface read from it instead of keeping its own copy flavor. Buy the commodity around the edges with a clear conscience. But own the spine and the seams, because that’s the part that’s yours and that’s the part that compounds.
In this process, build it to a standard you’d be willing to expose to an agent, even if you have no intention of doing so yet. Identity on everything. Least privilege everywhere. An audit trail for every mutation. Tests that gate the deploy. Not because the robots are coming, but because that standard is just what “well-built” means, and it happens to be the same standard that leaves the door open to automation when you’re ready to walk through it. (Plus, let’s be real, the robots are already here… dun dun duunnnnnnn)
My previous post on this topic was about velocity - about how cheap it had become to build instead of buy. This one is about what that velocity actually buys: coherence, an estate that both your people and your agents can reason about as a whole, instead of getting lost in the seams between a dozen things that were never meant to talk to each other. None of this was about doing less work, either; it was about deleting the menial, quotidian work so the real work has room to breathe. Every hour the system claws back from re-keying a project code, chasing an invoice, or reconciling a timesheet is an hour that goes where it belonged the whole time: into the hard, interesting problem sitting in front of a client. The automation just clears the runway to that work.
Build or even buy the islands if you must, but the causeways are your business. If you pour them straight, you’ll find you’ve built something that’s ready for a kind of leverage you weren’t even aiming at yet.
Tokenmaxxing or just scratching the surface? Would love to hear your experiences in the space and how you’re building and securing your AI stack to empower your business.