30 mistakes I see enterprises make with AI transformation: 1. Buying AI licences and calling it a strategy. Decide which problems you want to solve, how people will use the tools and what improvement you expect to see. Access alone doesn’t answer those questions. 2. Expecting every employee to become an AI engineer. People need different levels of training and responsibility. Helping someone use AI in their work doesn’t automatically prepare them to build and maintain a system for others. 3. Asking AI for answers before agreeing on what a good answer looks like. Start with real examples and clear criteria. Keep verified corrections as test cases, and rerun those tests when you change the system. 4. Blaming the model before checking the whole setup. A failure can come from the model, instructions, missing information, tools or the surrounding software. Investigate where it went wrong before deciding what to replace. 5. Automating a process nobody can explain from start to finish. We spoke to a team whose work moved between calls, emails, spreadsheets and shared folders. Understanding how the work actually got done was a substantial job in itself. 6. Giving an agent more access than its job requires. Limit what it can read and change, and require approval for consequential actions. Enforce those permissions in the software. An instruction telling the agent to be careful is not an access control. 7. Making data protection depend on someone remembering to delete a name. Use appropriate access controls and automated checks to limit sensitive information before it reaches the model. Removing names alone won’t address every way confidential information can be exposed. 8. Letting an agent spend money without a limit. We still meet teams with no budget cap. Set spending limits, request limits and stopping conditions, then decide what the system should do when it reaches them. 9. Counting AI usage as proof of business progress. Token consumption can help you understand adoption and cost. It doesn’t tell you whether useful work got finished. Measure results, quality and the time spent reviewing or fixing the output. 10. Letting company data end up in accounts nobody has checked. Know which services employees use, what happens to the information they enter and which settings and agreements apply. Make the approved way of working clear. 11. Choosing a model without considering what switching would involve. Understand which parts of your system depend on that provider. A different model may need different instructions and fresh testing, even when the technical connection is easy to change. 12. Paying for discovery without agreeing on what it must deliver. We heard about an engagement where the estimate kept growing, then the consultant left for another commitment. Set clear deliverables and a point at which you decide whether to proceed. 13. Committing to a plan with no way to act on what you learn. A long project isn’t automatically a mistake. The problem is having no checkpoints where real results can change the priorities or the proposed solution. 14. Launching an agent nobody is responsible for. Assign responsibility for its operation, monitoring, updates and eventual retirement. The people responsible need the authority and resources to do those jobs. 15. Buying a custom system without a plan for when the supplier leaves. Agree on documentation, access, support and handover while the relationship is working. Know who could maintain it if that relationship ended. 16. Waiting for users to tell you something has broken. You should have telemetry installed so you don't find a problem weeks later than you should have. 17. Making an agent read everything to find one thing. Give it tools that search, filter and return relevant information. Large responses full of unrelated data consume context and make the task harder to handle reliably. 18. Letting the people who built it be the only people who test it. Involve the people who do the job and understand the business. They can help identify answers that look reasonable but would cause problems in practice. 19. Testing only the situations where everything goes smoothly. Include exceptions, ambiguous requests and cases where the system should stop or ask for help. Confusing five cases with five individual items is exactly the sort of mistake your tests should catch. 20. Keeping essential knowledge in the heads of people who might leave. One company was trying to capture how experienced colleagues made decisions before they retired. Record their reasoning and examples while they can still explain and check them. 21. Assuming every AI project must wait for the ERP migration. Some read-only work may be possible against existing data. Check freshness, permissions and the work needed to adapt it later. A replica can help, but it may lag behind the live system. 22. Assuming one company’s AI success will transfer to the whole portfolio. Use that success as a starting point. Each company still needs to check whether the approach fits its work, data and business needs. 23. Expecting AI to understand terms your own departments use differently. Explain business terms, calculations and database fields. If several measures could reasonably mean “sales,” specify which one applies to the question. 24. Producing code faster than anyone can review it. Research describes how faster generation can increase the burden on reviewers. We spoke to a team where changes were piling up because every one still needed manual acceptance testing. 25. Hiring an AI engineer and assuming the rest will sort itself out. That person still needs a clear problem, access to useful data, suitable infrastructure and colleagues who understand the work. Hiring doesn’t remove those responsibilities from the business. 26. Expecting people to forget the last failed pilot. Earlier disappointments can make people less willing to trust another system. Find out what went wrong and show what has changed before asking them to invest their time again. 27. Calling a project “90% done” before testing the difficult workflows. We’ve seen projects move quickly, then spend weeks on a couple of remaining workflows. Check what is still unproven before using the feature count to estimate the work left. 28. Expecting an agent to follow rules it cannot access. Pricing exceptions, product substitutions and informal agreements may live in someone’s spreadsheet. Make the relevant rules available, keep them current and test whether the system applies them correctly. 29. Feeding AI conflicting numbers without explaining the differences. Systems may use different definitions, update schedules or reporting periods. Establish which source and definition apply to each question before expecting a dependable answer. 30. Assuming a data feed contains the whole picture. Check which customers it covers, which fields are missing and how far back it goes. Make those limitations visible so users know what the answer is based on. What else?

A US financial services company scoped three infrastructure projects for five engineers across two quarters. Our two-person Velocity Pod delivered all three in one quarter: automated funds movement, an underwriting portal, and investor access. I want to explain what made that possible, because “two engineers using AI” leaves out most of the useful information. The platform was already processing live transactions. Existing code, existing integrations, existing customers whose money had to keep moving. An audit found several things preventing the agents from working reliably. Domain rules weren’t documented clearly. Build and test commands were difficult to discover. Different modules followed different conventions. Recurring tasks had no established procedure the agent could follow. So the agents filled in the gaps themselves. That is a pretty expensive place to let software guess. We documented the architecture, domain terminology, coding conventions, and exact verification commands at both repository and module level. We also packaged recurring procedures into reusable skills. Adding an endpoint or writing a migration now had a documented approach. Every task started with a specification. Tests came before implementation. Every change passed automated verification before merge, with a PR review agent checking against the spec and project standards. All three projects used a shared architecture, so each subsequent project started with a foundation already in place. The result: 60% fewer engineers than planned, half the estimated timeline, and about $200 in AI compute per developer per month. The lesson I’d take from this is that your codebase contains less of your company’s knowledge than you think. Your experienced engineers know which conventions matter, where the exceptions live, and why something was built a particular way. An agent needs access to that knowledge too. Making it explicit is part of the engineering work. That’s what our Velocity Framework was built for.

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.

30 mistakes I see enterprises make with AI transformation: 1. Buying AI licences and calling it a strategy. Decide which problems you want to solve, how people will use the tools and what improvement you expect to see. Access alone doesn’t answer those questions. 2. Expecting every employee to become an AI engineer. People need different levels of training and responsibility. Helping someone use AI in their work doesn’t automatically prepare them to build and maintain a system for others. 3. Asking AI for answers before agreeing on what a good answer looks like. Start with real examples and clear criteria. Keep verified corrections as test cases, and rerun those tests when you change the system. 4. Blaming the model before checking the whole setup. A failure can come from the model, instructions, missing information, tools or the surrounding software. Investigate where it went wrong before deciding what to replace. 5. Automating a process nobody can explain from start to finish. We spoke to a team whose work moved between calls, emails, spreadsheets and shared folders. Understanding how the work actually got done was a substantial job in itself. 6. Giving an agent more access than its job requires. Limit what it can read and change, and require approval for consequential actions. Enforce those permissions in the software. An instruction telling the agent to be careful is not an access control. 7. Making data protection depend on someone remembering to delete a name. Use appropriate access controls and automated checks to limit sensitive information before it reaches the model. Removing names alone won’t address every way confidential information can be exposed. 8. Letting an agent spend money without a limit. We still meet teams with no budget cap. Set spending limits, request limits and stopping conditions, then decide what the system should do when it reaches them. 9. Counting AI usage as proof of business progress. Token consumption can help you understand adoption and cost. It doesn’t tell you whether useful work got finished. Measure results, quality and the time spent reviewing or fixing the output. 10. Letting company data end up in accounts nobody has checked. Know which services employees use, what happens to the information they enter and which settings and agreements apply. Make the approved way of working clear. 11. Choosing a model without considering what switching would involve. Understand which parts of your system depend on that provider. A different model may need different instructions and fresh testing, even when the technical connection is easy to change. 12. Paying for discovery without agreeing on what it must deliver. We heard about an engagement where the estimate kept growing, then the consultant left for another commitment. Set clear deliverables and a point at which you decide whether to proceed. 13. Committing to a plan with no way to act on what you learn. A long project isn’t automatically a mistake. The problem is having no checkpoints where real results can change the priorities or the proposed solution. 14. Launching an agent nobody is responsible for. Assign responsibility for its operation, monitoring, updates and eventual retirement. The people responsible need the authority and resources to do those jobs. 15. Buying a custom system without a plan for when the supplier leaves. Agree on documentation, access, support and handover while the relationship is working. Know who could maintain it if that relationship ended. 16. Waiting for users to tell you something has broken. You should have telemetry installed so you don't find a problem weeks later than you should have. 17. Making an agent read everything to find one thing. Give it tools that search, filter and return relevant information. Large responses full of unrelated data consume context and make the task harder to handle reliably. 18. Letting the people who built it be the only people who test it. Involve the people who do the job and understand the business. They can help identify answers that look reasonable but would cause problems in practice. 19. Testing only the situations where everything goes smoothly. Include exceptions, ambiguous requests and cases where the system should stop or ask for help. Confusing five cases with five individual items is exactly the sort of mistake your tests should catch. 20. Keeping essential knowledge in the heads of people who might leave. One company was trying to capture how experienced colleagues made decisions before they retired. Record their reasoning and examples while they can still explain and check them. 21. Assuming every AI project must wait for the ERP migration. Some read-only work may be possible against existing data. Check freshness, permissions and the work needed to adapt it later. A replica can help, but it may lag behind the live system. 22. Assuming one company’s AI success will transfer to the whole portfolio. Use that success as a starting point. Each company still needs to check whether the approach fits its work, data and business needs. 23. Expecting AI to understand terms your own departments use differently. Explain business terms, calculations and database fields. If several measures could reasonably mean “sales,” specify which one applies to the question. 24. Producing code faster than anyone can review it. Research describes how faster generation can increase the burden on reviewers. We spoke to a team where changes were piling up because every one still needed manual acceptance testing. 25. Hiring an AI engineer and assuming the rest will sort itself out. That person still needs a clear problem, access to useful data, suitable infrastructure and colleagues who understand the work. Hiring doesn’t remove those responsibilities from the business. 26. Expecting people to forget the last failed pilot. Earlier disappointments can make people less willing to trust another system. Find out what went wrong and show what has changed before asking them to invest their time again. 27. Calling a project “90% done” before testing the difficult workflows. We’ve seen projects move quickly, then spend weeks on a couple of remaining workflows. Check what is still unproven before using the feature count to estimate the work left. 28. Expecting an agent to follow rules it cannot access. Pricing exceptions, product substitutions and informal agreements may live in someone’s spreadsheet. Make the relevant rules available, keep them current and test whether the system applies them correctly. 29. Feeding AI conflicting numbers without explaining the differences. Systems may use different definitions, update schedules or reporting periods. Establish which source and definition apply to each question before expecting a dependable answer. 30. Assuming a data feed contains the whole picture. Check which customers it covers, which fields are missing and how far back it goes. Make those limitations visible so users know what the answer is based on. What else?

An IBM engineer explained agent harnesses in 20 minutes at @aiDotEngineer, and it's the best tutorial you'll find anywhere. Tejas Kumar gave GPT-3.5 one job, upvoting a Hacker News post. The agent hit a login screen and still reported success, and he fixed it without changing the prompt. People are paying $500 for agent courses that teach less than this. Watch it, then read the article on the slow death of the enterprise below.

A performance marketing platform with paying advertisers asked us to make their product operable by AI agents. We delivered the foundation in six weeks, the MCP service twelve weeks later, and the client's CTO now ships production code through his own AI harness inside gates we built. I want to walk through how, because "AI-enabled adtech" is on every deck in the category and almost none of it means an agent can operate the platform. Their codebase had real advertisers, real offer configurations, and real money moving through conversion data. This is brownfield, not a weekend prototype demo. February and March, we didn't touch AI. We built the foundation the agents would need: versioned management APIs, a dedicated API key type with its own authorization gating, an SDK surface, published Swagger docs. Teams skip this constantly. They wire a model to the UI endpoints, the payloads are ten times too large for an agent's context, the first write corrupts a live offer, and the pilot dies. I've seen it across 100+ engagements. When someone says "our platform isn't ready for agents," they almost always skipped the API surface. June 9, the MCP service went live. Tenant-scoped, read-only by design. Offer listings, change logs, performance summaries, conversion data. An early user couldn't damage a live configuration because there was nothing to damage with. July 1, the first write tools: pause, share, clone an offer, update a conversion status. July 9, the second wave: update offers, resume paused ones, create ad-hoc conversions for integrators. The endpoints were purpose-built for language models. Narrow summary calls, current-date context injected for month-only queries, response-size caps, latency work. Large payloads break agent workflows, so the surface was designed around the agent rather than reused from the UI. Their CTO ships production code himself, through his own AI agent harness. We own the API surface, the architecture, code review, QA and release. Same repository, same board, same branching strategy, same quality gates, with guardrails enforced at GitHub level. April 14 was the first production delivery from that workflow: a query optimisation where the agent validated its own work by diffing old and new SQL against production data, row for row. The release count came from three things: automated AI review on every pull request since January, tests scoped from the PR diff with the bulk of new test code generated, and a documentation set of around 70 system documents kept in the repository so it doubles as context for the agents. Behind it, this engagement is one of the first two pilots for Velocity Core, our own agentic delivery system. A ticket status change fires a webhook, an isolated agent plans, executes, runs CI and opens a PR for human review. When CI fails, the failure and the developer's fix are recorded and served back to future runs. Alpha, tested on real tickets, with the client's CTO inside the loop. Their CEO connected his own AI assistant to the platform. As far as we know, very few platforms in performance marketing can say that today. That's what our Velocity Framework was built for.

A US financial services company scoped three infrastructure projects for five engineers across two quarters. Our two-person Velocity Pod delivered all three in one quarter: automated funds movement, an underwriting portal, and investor access. I want to explain what made that possible, because “two engineers using AI” leaves out most of the useful information. The platform was already processing live transactions. Existing code, existing integrations, existing customers whose money had to keep moving. An audit found several things preventing the agents from working reliably. Domain rules weren’t documented clearly. Build and test commands were difficult to discover. Different modules followed different conventions. Recurring tasks had no established procedure the agent could follow. So the agents filled in the gaps themselves. That is a pretty expensive place to let software guess. We documented the architecture, domain terminology, coding conventions, and exact verification commands at both repository and module level. We also packaged recurring procedures into reusable skills. Adding an endpoint or writing a migration now had a documented approach. Every task started with a specification. Tests came before implementation. Every change passed automated verification before merge, with a PR review agent checking against the spec and project standards. All three projects used a shared architecture, so each subsequent project started with a foundation already in place. The result: 60% fewer engineers than planned, half the estimated timeline, and about $200 in AI compute per developer per month. The lesson I’d take from this is that your codebase contains less of your company’s knowledge than you think. Your experienced engineers know which conventions matter, where the exceptions live, and why something was built a particular way. An agent needs access to that knowledge too. Making it explicit is part of the engineering work. That’s what our Velocity Framework was built for.

A performance marketing platform with paying advertisers asked us to make their product operable by AI agents. We delivered the foundation in six weeks, the MCP service twelve weeks later, and the client's CTO now ships production code through his own AI harness inside gates we built. I want to walk through how, because "AI-enabled adtech" is on every deck in the category and almost none of it means an agent can operate the platform. Their codebase had real advertisers, real offer configurations, and real money moving through conversion data. This is brownfield, not a weekend prototype demo. February and March, we didn't touch AI. We built the foundation the agents would need: versioned management APIs, a dedicated API key type with its own authorization gating, an SDK surface, published Swagger docs. Teams skip this constantly. They wire a model to the UI endpoints, the payloads are ten times too large for an agent's context, the first write corrupts a live offer, and the pilot dies. I've seen it across 100+ engagements. When someone says "our platform isn't ready for agents," they almost always skipped the API surface. June 9, the MCP service went live. Tenant-scoped, read-only by design. Offer listings, change logs, performance summaries, conversion data. An early user couldn't damage a live configuration because there was nothing to damage with. July 1, the first write tools: pause, share, clone an offer, update a conversion status. July 9, the second wave: update offers, resume paused ones, create ad-hoc conversions for integrators. The endpoints were purpose-built for language models. Narrow summary calls, current-date context injected for month-only queries, response-size caps, latency work. Large payloads break agent workflows, so the surface was designed around the agent rather than reused from the UI. Their CTO ships production code himself, through his own AI agent harness. We own the API surface, the architecture, code review, QA and release. Same repository, same board, same branching strategy, same quality gates, with guardrails enforced at GitHub level. April 14 was the first production delivery from that workflow: a query optimisation where the agent validated its own work by diffing old and new SQL against production data, row for row. The release count came from three things: automated AI review on every pull request since January, tests scoped from the PR diff with the bulk of new test code generated, and a documentation set of around 70 system documents kept in the repository so it doubles as context for the agents. Behind it, this engagement is one of the first two pilots for Velocity Core, our own agentic delivery system. A ticket status change fires a webhook, an isolated agent plans, executes, runs CI and opens a PR for human review. When CI fails, the failure and the developer's fix are recorded and served back to future runs. Alpha, tested on real tickets, with the client's CTO inside the loop. Their CEO connected his own AI assistant to the platform. As far as we know, very few platforms in performance marketing can say that today. That's what our Velocity Framework was built for.

Hot take: 90% of what the market calls "agentic AI" is just fancy RPA with a reasoning layer. Same intake. Same routing. Same decision tree. The difference is unstructured input and an LLM making judgment calls instead of hardcoded if/else. That's it. It's not less valuable because of this. It's actually MORE valuable because it means we finally know what we're building: reliable, testable automation for business operations that actually changes how a company works. But the industry keeps wrapping it in sci-fi language because "intelligent process automation with decision graphs" doesn't get funding decks approved. The companies actually shipping AI into production right now aren't chasing AGI. They're mapping processes, identifying where human judgment is wasted on repetitive decisions, and building systems that handle those decisions at 10x speed with an audit trail. That's it. That's the whole game. The firms that understand this are compressing labor costs by 25-40% on their service delivery lines within 90 days. The ones waiting for "real AI" are still running pilots.

The smartest person in your company is your biggest bottleneck. A PE operating partner introduced us to a medical billing company that processes claims for hundreds of healthcare facilities. The co-founder spent roughly ten hours a week writing queries against a 20-year-old database to produce financial health assessments for prospects. No dashboard could replace her. Dashboards answer the questions someone already thought to measure. She answered the ones nobody anticipated: ad-hoc queries against prospect data that changed with every deal. The operating partner saw it before our first call. Key-person dependency on the co-founder, manual analytical processes consuming executive hours, and a leadership team that knew the problem but couldn't solve it internally. We put one AI Velocity Pod on it: one senior AI engineer, a fractional AI lead, and a fractional delivery lead. We sat with the co-founder for three weeks before writing any agent logic. Denial definitions, remittance joins, evaluation order. All of it encoded as structured reasoning the agent follows on every question. Vetted KPIs so answers reconcile to the penny against her known-correct outputs. Then we built the evaluation harness: golden questions with known correct answers, automated judges, and regression checks against the actual database. The harness existed before the agent did. Six weeks from the PE introduction, the head of product was running real analytical questions through a working agent on live claims data. > $200-$300 a month in compute > Read-only agent inside the client's cloud boundary > Every answer goes through human validation On the day it went live, the co-founder ran a question that normally took four hours. Answer in under a minute. Every reasoning step traced to the source tables. Of the ten hours a week she'd been spending on queries, nine went back to running the business. Compare that to a typical enterprise AI pilot: six to twelve months, $500K or more in consulting fees, and a slide deck as the deliverable.