PE-backed roll-ups keep asking the same question: do we need to fix our data before we can use AI? Most of the proposals they receive say yes. I don't agree that fixing everything has to come first. A PE investor described one of their platform companies to me: a home-services business that had grown through acquisitions. Each business brought its own systems. Reporting was fragmented, month-end close was manual, and someone consolidated the books by hand. The usual AI proposal starts with a migration. Move everything into one data lake, build clean data products, then give the models access. That's a year of work before anyone sees an agent do something useful. Those systems already run the business, and the business makes money using them. We can leave the systems of record in place and build what's needed around them: controlled access, a model gateway and logging for every call. Then choose one workflow, such as month-end reconciliation, and work across the existing systems. That still requires data work. I'd make it specific to the workflow: - Source mapping: which system holds each required field, and how do customer or account identifiers line up? - Metric definitions: do the companies mean the same thing by revenue, bookings or a completed job? - Data quality checks: which missing or inconsistent values prevent this workflow from running? - Permissions: what can the agent read, propose or change? - Reconciliation: how will finance check the output against the underlying records? - Exceptions: where does uncertain or conflicting information go for human review? That is a bounded integration problem. You can define what has to be true for the first workflow without redesigning the entire data estate. Consolidation may still be worthwhile. You will make a better decision about it after seeing which data the workflow actually needs and where the recurring problems are. If the first AI proposal for one of your portfolio companies starts with a migration, ask what ships in month one.

Avoid hiring an AI consultancy. Avoid hiring an AI consultancy. Avoid hiring an AI consultancy. Avoid hiring an AI consultancy. Avoid hiring an AI consultancy. Avoid hiring an AI consultancy. THE FIRST REASON IS:

3 mistakes I see even great CEOs make with AI: 1. Expecting AI to understand a business nobody has written down. You buy seats, open a blank chat and ask how to improve margins. But the model has never seen a contract, read a customer complaint or heard why you lost your biggest account last year. You wouldn't hand pricing decisions to a smart stranger without explaining the business. Someone has to write down how it works and give AI that context before the answers become useful. 2. Letting every leader use it alone. Your CFO has a great prompt for the board pack, sales has built its own, and ops hasn't started. Nobody shares what they've learned, so the lessons stay buried in individual chat histories. Ask each leader to show the team how they're using AI to get work done. Our engineers work from one shared knowledge base and one set of skills, and we can see who uses which skill and how often. 3. Chasing every new model instead of building what compounds. A new model ships, and your leadership team spends a week comparing it with the last one. It's easy to get caught in that whirlwind when whatever you choose this quarter will be replaced next quarter. Meanwhile, the pages you write about how you price, why customers leave and what good work looks like in your business become more valuable every month, whichever model reads them. Models are replaceable. Swap them the day a better one ships. Your context and your judgment aren't. Spend your time there.

Every PE call I've had this quarter ends up at the same AI problem: nothing is getting shipped. I've heard it from operating partners, CFOs, a holdco's AI lead and someone about to join a portco board. - One fund now puts its own engineers inside each portco and calls them "almost special ops" - a CFO sees more pull requests than ever and a codebase that isn't getting any better. - a holdco learns the same lesson from zero in every company it buys. - plenty of portcos have one technologist who has decided that makes them the AI strategy. - a new board member's whole brief is choosing which AI firms to trust. None of them are doing anything wrong but AI moved faster than their operating models did. What helps is one workflow, shipped and measured, then taken to the next company. That's what we've done for clients for 10 years.

Every week another "AI transformation partner" turns up with "agentic" in their tagline and case studies from clients nobody can name. A CTO at a financial software company told our team about the ones who'd already pitched them. They'd sorted them into four groups before we asked. First, the "AI-powered" outsourcers. In the CTO's words, they "talk a big game" and then it's "offshore people clicking AI buttons." Then the "AI experts," who "come in and can talk but don't seem to do anything at all." Then the "Applied AI" startups with their own platform, who wanted a regulated company to move its whole stack onto something that isn't SOC 2 certified yet. And the "AI engineer" placement firms, whose plan was seven hires at $300,000 a year each. What the CTO actually cared about came out a few minutes later: "If you guys don't produce, I just blew the rest of my year." None of those pitches had an answer for that. We've been an engineering firm for 10 years, since long before anyone called it "Applied AI." I replied: "If we don't deliver, you don't pay."

A PE operating partner asked us to build production AI agents inside a portfolio company's billing system, processing real healthcare claims under HIPAA. Two people hand-wrote every rule in their claims engine across 300+ denial codes and payer logic that changes quarterly. Four months later, seven production agents handle it with zero patient data exposure. First month, we didn't touch a model. We mapped their data: where it sits and what's missing, so agents reason from structured facts instead of guessing. I've watched teams skip this step across dozens of engagements. They bolt a model onto the product, watch it hallucinate over unstructured inputs, and decide AI isn't ready for their industry. The data work is what makes it ready. We built an enrichment layer that assembles 34 dynamic variables per claim before any LLM sees it, pre-computed and versioned so the agent receives ranked facts instead of searching for context. Every agent follows one pattern: pre-compute context, strip all patient data before the model sees it, validate output against a strict schema, let deterministic code accept or reject the action. If the output falls outside the allowlist, the system fails closed. Seven agents, each locked to a single workflow like denied claim follow-up or billing reconciliation, each running its own enrichment payload. Then we built the eval harness. Every agent runs against a curated test suite before any update reaches production. When a model provider ships a new version or payer logic changes, the harness catches regression before a single live claim is affected. The flagship agent reconciles denials to the penny: 59 out of 60 on the eval set. Most teams launch an agent and hope it keeps working. We launch one and prove it does on every deployment. We route calls across two model providers. Swapping one changes nothing in the output because the eval harness verifies it. Model integration was the shortest line item in the four-month build. The operating partner now benchmarks the rest of the portfolio against this system. That's the line between a portfolio company running AI and one still running demos.

Every week my feed is full of autonomous agent swarms running 24/7. Meanwhile, enterprises are still leaving private keys and database passwords in Git repos. Before you give another agent production access, make sure someone has handled: > private keys and database passwords kept out of source code, including private repositories > secrets kept out of Slack messages, support tickets and AI chat history > backend credentials kept out of the JavaScript every visitor downloads > a secrets manager where access to one application's credentials doesn't reveal everybody else's > push protection that blocks detected secrets before they reach the repo, with bypasses reviewed > secret scanning that checks Git history, because deleting the file leaves the old commits > secret checks on container images and build artifacts, because a clean repo doesn't mean a clean release > revoking exposed credentials and checking that sessions and tokens already issued from them can no longer access the system > short-lived credentials wherever the infrastructure supports them > a way to rotate the remaining long-lived keys without taking the application down > separate credentials for development, staging and production > a named owner for every service account, integration and API key > removing the credentials for the experiment everyone abandoned six months ago > download links limited to the intended file, with an expiry > individual admin accounts, so the audit log can identify an actual person > phishing-resistant MFA for human access to email, Git, cloud consoles and privileged accounts > the forgotten test account covered by the same security requirements > account recovery that doesn't let a convincing phone call bypass MFA > temporary elevated access that expires when the work is finished > offboarding that revokes sessions, tokens and SSH keys as well as the employee's login > contractor access that ends when the contract does > access reviews where someone actually removes permissions > tested emergency access that still works when normal sign-in fails, with every use logged and alerted > permissions that deny access unless it has explicitly been granted > a reporting service that can read the database without being able to delete it > an invoice integration that doesn't need administrator access to the entire cloud account > OAuth permissions limited to the job the integration actually performs > access tokens whose signature, issuer, audience and expiry are actually checked > authorization checked on the server for every request > checks that stop one customer reading another customer's invoice by changing the ID > the same customer isolation in search, exports and file downloads > tests that prove forbidden actions fail > production databases and admin interfaces restricted to the access paths they actually need > customer documents in storage that isn't accidentally public > separation between test and production, so compromising a demo doesn't unlock the business > deployment credentials scoped to the application being deployed > untrusted pull requests kept away from production secrets > reviewed, locked versions of the third-party code running inside the deployment pipeline > approval required for changes to the pipeline and its security rules > logs that record access and permission changes without recording the credentials themselves > audit records the application cannot quietly erase after it has been compromised > alerts for new privileged accounts, suspicious logins and unusual data exports > backups protected by permissions that stop a compromised production account deleting them too > a restore someone has actually tested > a recovery plan for compromised signing and encryption keys, including the data and tokens they protected > a person responsible for patching exposed systems and vulnerable dependencies > AI agents with identifiable accounts and access limited to their assigned work > permission checks that stop an agent using its service account to fetch data the requesting user cannot access > production credentials kept out of the agent's prompts, files and shell environment, with authenticated operations handled by a restricted execution service > tool permissions enforced by code outside the model > outbound network access limited to approved destinations > tests for malicious instructions in documents, tickets and tool responses the agent reads > single-use, expiring approvals tied to the person, action, target and parameters, checked immediately before execution > an agent that cannot grant itself more permissions or approve its own request > limits on tool calls, bulk exports and spending, so a permitted action cannot repeat without a ceiling > a tested way to stop the agent and revoke its access > independent verification of urgent payment or access requests through a known, trusted channel, even when the voice sounds exactly like the CEO Oh, and someone still has to own this after launch: > deciding who needs access > removing it when the job changes > investigating the alerts > fixing what the scans find > checking that the fix actually works > answering the phone when production is compromised Your agent swarm may work 24/7. So does the production key nobody revoked. We go into enterprises with working, profitable software and still find ridiculous security holes. Book a call with us if you need enterprise AI implementation done the right way.

A delivery orchestration platform that supplies FedEx estimated it would take 7 to 8 months to rebuild its core billing system. We rebuilt the core in 3.5 months with 2 engineers, merging 122 pull requests in the first 90 days. The system was in production by month 6. The core was ready in roughly half the estimated time. Getting it into production took longer. The old system was a no-code tool that had grown into their billing engine. It invoiced shippers, paid carriers and handled disputes, but it was slow. Many of its rules weren't documented anywhere. We had to work them out from production data. Their engineering teams usually had 5 to 10 people. Our pod had 2 full-stack engineers, supported by an AI productivity lead and a part-time PM. It was also the first AI Velocity Pod we'd ever run. Three things made the difference. 1. Context before code. For the first two weeks, nobody wrote feature code. We scanned the repo and built a knowledge graph covering every module, data flow and domain term. Some of the work involved building new code, and some connecting to systems other teams already depended on. The agents read that map before working on either. 2. The agent asked before it built. Every feature started with a written spec, even as requirements changed daily. Before planning one feature, the agent asked how the system would know which costs belonged to the shipper and which belonged to the carrier. Nothing in the code answered that question. Resolving it during planning is straightforward. Discovering it on a live invoice means dealing with a dispute. 3. Engineers designed and reviewed. The agent typed. The agent wrote about 90% of the code. Nothing merged unless our engineer could verify it, explain it and debug it without the agent. The client's principal engineer also reviewed every PR. Of the first 122, 104 had fewer than 5 reviewer comments. Then came the rollout. A small group of logistics providers tested it in October. It went live in December, and the old system was switched off early this year. We merged about as many PRs in the two months after go-live as in the four months before it. AI compute cost about $200 per developer per month. Their CTO called our pod the "top performing team" inside the company. Both engineers received discretionary bonuses, twice. The client then hired more of our engineers. Next time a portco brings you a 7 to 8 month estimate, ask how much of it is discovery nobody has done yet.

Book a discovery call if you want to ship AI-native: meetings-na2.hubspot.com/mar…

My friend just got paid to help a company adopt AI €800k engagement I helped with the proposal (I changed "automation" to "agentic transformation") He's already delivered 2 maturity assessments, 3 strategy decks, and 17 stakeholder alignment workshops Has enough follow-up workshops booked to keep the transformation going for about 18 months They are currently pre-code and pre-ROI I urged him to run another readiness assessment instead of building the pilot, but otherwise I'm happy with his decisions so far Love seeing enterprises take AI seriously