The Agentic Integration Awakening
PUBLISHED
October 29, 2026
Earlier this year, Bessemer Venture Partners published The Agentic Awakening, a playbook for engineering leaders built on interviews with more than twenty CTOs. Its central finding is uncomfortable: most companies underestimate the journey to transform software engineering teams to be AI-native.
Even among more advanced users who may see 10x faster code generation, the enterprise reality is most of that gain is absorbed by surrounding processes and shifting bottlenecks.
We read the playbook closely because we’ve been navigating this gap for 18 months. And as we’ve applied AI coding ourselves, we’ve built the AI-native integration solution for our customers.
These are teams who connect the ERP to the CRM, the warehouse to the storefront, the thirty-year-old mainframe to the three-month-old AI agent. When a software team ships a feature in a day and then waits three weeks for it to reach the systems of record, we're the ones who get the call.
The Digibee platform gives integration teams everything they need to shift to AI-native integration: the intelligence, the harness, and the methodology for people to partner with AI.
This is not a rebuttal to Bessemer’s framework; we strongly recommend reading it. This is a "yes, and." Integration is a subset of software engineering. Almost everything in the playbook applies to integration teams directly, but integration has its own shape.
Reading the Bessemer piece was like watching a movie portraying a life we’d lived.
In early 2025, we anticipated the monumental potential for agentic AI to relieve the pressure valve for overburdened integration teams. This was before the big model providers cracked the formula on AI-generated code, but we saw the wave coming.
As you’d expect, our AI engineers started with prompts. They spent many cycles optimizing, and while they got the LLMs to produce workflows that looked plausible on the surface, they didn’t hold up on production. It was humbling. Setbacks like this are part of software development, but as founders of a company born on the cutting edge of cloud technology, it frustrated us that building into the next frontier proved so difficult. We took a step back to assess the scope beyond prompting generic coding agents.
Our platform itself needed to be rearchitected. Its user interface and supporting APIs were built to serve human users; agentic users have different needs. The connectors and runtime underneath were sound, and they became the foundation for everything that followed. We started to see real, sustained progress.
Next we needed to define and build the right roster of deeply specialized sub-agents. We embedded decades of integration knowledge and experimented our way into the best model to power each task.
Beyond technology, we had to reimagine how people work: guiding, collaborating with, and delegating to AI. The critical surface for this became the specification, which along the way solved a ubiquitous pain point: undocumented workflows.
Finally, as we share in Part II, we had to learn how to build the buy-in and confidence to bring people along the way. We had our stumbles, recovered, and now bring our learnings to you.
–Peter Kreslins, Co-founder and CTO, Digibee
We wrote this for two readers. The first is the CIO or VP of Integration who wants to know what the agentic shift means for their team, their backlog, and their people. The second is the AI platform engineering leader on Bessemer's side of the fence, who may not yet see how much of their 50% ceiling is an integration problem. There’s a dedicated section for that reader near the end.
The examples come from dozens of conversations with CIOs, architects, and integration engineers at companies ranging from startups to large enterprises, in manufacturing, finance, insurance, logistics, and software. Insights also come from Digibee’s Forward-Deployed Engineering and Professional Services teams who work inside customer estates.
Bessemer's first rule is to build the environment before you try to change the people. Buying AI tool licenses, whether seats for Copilot and Claude Code or an AI add-on to your integration platform, only opens the door.
The playbook measures the foundation on four dimensions: coding infrastructure, AI Ops, measurement, and security. We agree with all four, and here we translate them for an integration team.
The starting point is assessing where your teams are today. There are four levels from AI as an assistant all the way to an (as of yet) largely unrealistic autonomous team of agents operating in a “dark factory.”
Most integration teams we meet are at Level I. They're using an AI assistant in their integration platform, or they're asking Copilot for a line of code. The test is the same one Bessemer applies to engineering: is a human still the throughput constraint? If every change waits on a person to type it, you are at Level I.
Level IV is a future promised by AI labs, and one we see as possible long-term, but not an attainable near-term goal. Given integration is the backbone of mission-critical enterprise operations, the bar is high. Long before this gate is feasible from a technical standpoint, enterprises will first need to define the gates for AI to prove trustworthiness and expertise not just broadly across the organization, but on specific integration uses.
When integration teams expand capacity and ease friction, more of the estate ends up centralized and governed. The integration team still decides which systems require a human in the loop, which classes of integration an agent can build without approval, and what the logs must capture. Some organizations with well-documented estates will wade into Level IV within a couple of years. Those with disorganized estates, or no urgency to fix them, will take a decade or longer.
In Part I, under "How the Strongest Teams Build It," Bessemer argues that the coding agent is becoming a commodity, and the durable advantage is how context, tools, and skills reach the agent. For a coding agent, the most valuable context is often not in the repo at all. It is what the ERP accepts, how the CRM identifies a customer, which fields in billing are authoritative. That’s integration knowledge. A coding agent with an integration agent behind it is far more effective than one guessing at the enterprise from the outside.
If your team builds integrations with general-purpose coding agents such as Microsoft Copilot or Claude Code, assigning the goal isn't enough. These agents bring no integration expertise and no knowledge of your enterprise. The team has to supply the best practices, organizational standards, and strategy inputs that drive tradeoff decisions.
When building integrations with AI, teams must steer it away from its default pattern. General-purpose agents reach for the fastest plausible solution, and sometimes imagine shortcuts. Engineers at one of our customers watched a coding agent suggest NetSuite tables that didn't exist, joins on fields that weren't there, and data transformation scripts that ignored the platform they had to run in.
We have found the following strategies make agents perform better on integration work:
We make the fuller case for wrapping brittle legacy APIs in pipelines that own sequencing and error recovery, so an agent never touches that brittleness directly, in "Legacy APIs: AI Agents' Challenge and Opportunity."
Bessemer's measurement ladder runs from token usage to quality to productivity to benchmarks. The question underneath it is simple: are teams building the right solution for each problem, at the right cost? For integration, we measure four things:
One thing no agent settles is what the data means. For an agent to operate in your estate, it needs to understand the meaning of fields, properties, and states across your domains. A wrong connection breaks loudly. Divergent meaning doesn't break at all; each system stays internally coherent until the day an audit asks them to agree. Gartner puts the average cost of poor data quality at $12.9 million a year, with data source inconsistency as a meaningful factor.
System semantics define how one application behaves: why a vendor's data model is shaped the way it is. It's capturable, and an agent with a good connector library can absorb it.
Where agents struggle is semantic interoperability:
One of our customers described the common challenge of reconciling data to the right single person. Their donor records and ticket sales lived in separate systems that identified people differently; one used account IDs, and the other used customer email addresses. When they had to match records, they couldn’t be sure they had the right account ID/email pairing in each instance.
These cross-cutting semantics need to be captured and accessible for agents to effectively operate in the enterprise. The human process of chasing down which teammate across the company knows the answer to how a property definition in HR bridges to another in IT isn’t tenable for agents.
Now is the time to invest in documenting this institutional knowledge, and to build organizational discipline for ongoing curation.
Ideally this has a central owner: a central function with a mandate, not a side project. Many organizations don’t have one, especially at the bridges between systems. This gap gets more expensive as enterprises delegate domain operations to agents. A person reconciling two systems by hand eventually notices meaning drift, while an agent running a domain makes locally reasonable decision but doesn’t compare notes with the one next door.
Enterprise semantics decides what the data means when two systems disagree, such as when an order counts as shipped or which record is the real customer. As people or agents make these calls, they’re captured in project-level specs and then absorbed into organizational memory.
Bessemer lays out four risk surfaces for agentic security. The integration version has four risk surfaces of its own, each with a plain answer.
Integrations act directly on the systems and data that run the enterprise: the ERP, the customer records, the payment feeds. The agent that owns integrations shouldn't. It should design, build, and test in a sandbox for human approval before going to production.
When an integration agent (or a person) builds agents into steps inside a workflow the stakes are raised. Each integration holds the keys to important systems and, by design, accepts input from outside your organization. Put a model in that path, and an attacker can hide instructions in a partner file or an inbound webhook that turn those keys against you. Security teams call this a “confused deputy”: a trusted component tricked into misusing its own authority.
In February 2026, a GitHub issue title compromised Cline, an open-source AI coding assistant. Cline used Claude as a bot to triage new issues. An attacker wrote a title disguised as a tool error that told the bot to install the attacker’s package, which allowed the attacker to get Cline’s package publishing credentials. The attacker then published a rogue update that was live for about eight hours, and quietly installed an AI agent, OpenClaw, on machines that installed or updated Cline in that window.. The agent wasn’t malicious, but the vulnerability was proven to be exploitable.
The answer has two parts. First, keep models out of the hot path. Where a flow does include a model, it’s to augment the mission-critical workflow. Great use cases include classifying a document, extracting fields, or flagging an anomaly. An agent step shouldn’t write to a critical system of record; the deterministic pipeline around it does that.
Second, control access in one place. Every agent gets its own identity, with permissions granted, scoped, and revoked centrally. Credentials are brokered and short-lived, never pasted into a prompt or written into a spec.
When a team needs an agent to reach a new system, the request must go through the same gate as everyone else's, so no agent ends up with permissions handed out one-off and forgotten.
An integration agent built on a single LLM guarantees you don’t have the most effective nor cost-effective model behind every task your integration agents perform. Tokens for OpenAI’s most expensive LLM cost 200x more than its cheapest, but each has its place. Some handle schema mapping, error diagnosis, or documentation ingestion better than others, and the rankings change with every release.
Harvey, an AI platform for law firms, favors GPT-5.2 for long-form, well-sourced output, Claude Opus 4.6 for multi-step legal analysis, and Sonnet 4.6 or Gemini 3 Flash for high-volume, low-latency tasks.
Airbnb’s customer service agent draws on 13 LLMs from OpenAI, Google, Alibaba, and open-source projects. It leans hardest on Alibaba’s Qwen, which CEO Brian Chesky called “fast and cheap.” Closer to home, Digibee’s Digital Worker builds integration workflows mainly on Claude Sonnet 5.5, with Claude Haiku 5.5 and Gemini 3 Flash handling validation.
In addition to cost and performance optimization, cross-vendor LLM stacks create operational resilience. A fallback model keeps an agentic step running when a provider has an outage, and switching stays cheap if a provider changes its terms, pricing, or data retention.
Of course, making these choices takes dedicated capacity and expertise: evaluating models on real tasks, and doing it again with every major release. Most teams don’t have the resources to do so. In a mid-2025 Menlo Ventures survey of 150 technical leaders, only 11% had switched LLM providers in the past year. Two-thirds had upgraded within their existing provider, and nearly a quarter had changed nothing about their LLMs.
Digibee’s AI engineering team tested LLMs from Anthropic, Google, and OpenAI for the breadth of specialized tasks our digital workers perform, and re-tests as new releases arrive. Defaulting to a larger LLM is easy, but the team found that Haiku performed workflow validation nearly as well as Sonnet at one twentieth of the cost. “What It Took to Make an LLM Build Enterprise Integrations” describes how Digibee grades each build against expert-built reference integrations.
If you rely on a platform partner to build integration agents, ask how it picks an LLM for each task and how often it re-tests.
An integration built by an agent is only as trustworthy as your ability to explain it. You need to know why decisions were made, how things were built, and why changes were made—even eighteen months and four million executions later, when the person who approved them has moved on.
The answer is to govern through the specification. The agent captures every design decision as it makes it. Every human approval is attributed to a named person. This rigor doesn’t stop after workflows are deployed to production. Maintenance has to run through the spec, too, ensuring the spec remains an enduring source of truth. We make the fuller case in "Is the truth in your code or your spec?"
This satisfies the auditor, and does something more useful: any teammate can pick up any integration and understand why it was built the way it was. No knowledge is trapped in one head.
Integrations sit at the center of enterprise operations. When one fails, the cost is lost revenue, lost customer trust, and in regulated industries, fines.
For many workflows, agents shouldn't have autonomy to make decisions at runtime. Instead, put agents to work at build time.
Agents accelerate your path from intent to production code, and with the right harnessing and human collaboration, they make that output better. Give integration agents your objective and let them drive discovery and design for you. Have them capture their plan and raise tradeoffs to you to decide.
When the plan is complete enough (a judgement call you make), you delegate the build to your integration agent. They build to spec.
This keeps humans in the loop where it counts. Nothing goes live without a human approving it, directly or through a standing approval for its class. What ships to production is, in most cases, a primarily deterministic pipeline.
An integration's build is easy to verify and its live behavior isn't. As we flagged above, vendor sandboxes diverge from production where it matters; one engineer at a logistics company told us his team builds against a sandbox holding a fraction of production's records, and nothing fails until go-live.
So the human gate stays, and it has a cost. Another integration leader, this time at a large health insurer, told us the reviewer sets the pace for everything the AI generates.
Where integration agents can meaningfully improve the process is generating a suite of verification mechanisms that, when stacked, increase confidence. These can include mocks built from data contracts, contract tests, synthetic transactions, shadow runs, and reconciliation. They each catch some problems and miss others, but cumulatively bring strong coverage.
The human gate gets lighter as those layers prove themselves. Once an integration domain consistently passes enough verifications and has a record of running cleanly, engineers can approve it through policies and guidelines instead of reviewing every build.
Integration domains increasingly distribute across three buckets:
All integration domains would start in the human-guided tier. As the agent builds more projects within a domain that function properly in production, it gets more leeway. A domain may also move down a tier; when a vendor overhauls its API catalog, new integrations in the associated domain need more attention.
With the foundation in place, you're ready for the arguably harder stage: changing how your people think and work. This must be top-down, ideally with AI-pilled leaders showing their own initiative to transform how they work.
Handing over the tool isn't conversion, and you can't hire your way through it, because a new hire doesn’t know your estate. In most organizations, there’s one person per integration domain who knows why a mapping silently drops a field, why one partner gets custom retry logic, and which of two disagreeing systems tells the truth. That reasoning rarely gets written down.
Your people will sort themselves into four groups whether you name them or not. Integration teams have the same four groups Bessemer describes for software engineers, with a twist in the proportions.
For a Tool User, a peer's result makes the vision real, so put your Believers' real work in front of the team. Tool Users often use AI for a first-pass mapping or a boilerplate transformation and then build by hand, because nobody has shown them what it does on harder problems. Show them cases where it worked.
Resistant engineers look like Guardians from a distance, since neither uses the tools. The difference is the reason. Guardians have objections you can address. The Resistants don't, and more persuasion won't move them.
Integration engineers over-index to Guardians. This isn't an innate personality trait. It is what years of being the only person who knows why the invoice feed fails on the last day of the quarter does to someone.
The takeaway for the CIO: don't route around that knowledge. Encode it. The Guardian's job becomes teaching the agent what they know, in a form they can inspect and trust.
Integration talent is scarcer than engineering talent. Bessemer says you can't hire your way through the conversion. This is even more true for integration where the pool is smaller. A practical path here is to pair new, AI-native hires with career integration architects and engineers who know your estate, so each learns what the other knows.
Because Guardians are the largest group on most integration teams, they deserve a closer look. Bessemer identifies two sub-types. Architecture-bound Guardians are right that the estate isn't safe for integration agents yet; the fix is the system. Identity-bound Guardians may have a sound estate but resist the change to their role; the fix is the person.
Integration adds a third: the accountability-bound Guardian, whose concern is who’s held responsible when a workflow breaks.
Architecture-bound Guardians name preconditions: limited test environment for the ERP, no replay path, no contract tests, nobody positioned to approve the change. These are factual claims, not feelings. Convert this Guardian by addressing those facts.
Bessemer lists six plays for making a legacy stack agent-ready: the Verification Layer, the Headless Split, the Boundary Redraw, the Strangler, the Rewrite, and the Map. For integration, start with the Map. Almost no enterprise has one. While no survey counts integrations directly, the closest proxy, Flexera's 2026 State of ITAM survey, puts complete IT visibility at 36% of organizations. That's down from 43% the year before.
Documentation, or what we call the specification, serves as the integration estate's closest equivalent to a map. It’s also the first casualty of a capacity-constrained team. An engineer builds a working version on a tight deadline, intends to go back and document and harden it, and then the next fire drill arrives. Soon, you have an estate nobody can describe.
An integration engineer at a logistics company called his "like spaghetti"; his team spent months reverse-engineering pipelines into dependency graphs to see what they had.
An agent can't make the right calls about an estate it can't see. It doesn't know what exists, what's connected to what, or how. So the first agentic project for most integration teams is discovery: letting agents map the systems, data flows, and dependencies, and produce the documentation that never got written. The Map then becomes the context every later build draws on.
Believers and Tool Users are blocked by the missing Map, too. A converted engineer in an unmapped estate is paralyzed.
The rest of the plays follow from the Map. Brittleness in an enterprise isn't contained to a codebase you own. Much of it lives between third-party systems: a SaaS vendor's API, a partner's EDI feed, a mainframe nobody wants to touch. Only the integration layer reaches those.
For identity-bound Guardians, mastery, status, and control are at stake. In integration, we often hear "I could build this faster than I could explain it to AI." It sounds like rigor and a bias toward speed. Often it's a lack of buy-in.
The CIO's job here is not to argue. It's to make the future role believable, because the future role is better. The integration engineer moves from order-taker to advisor. Instead of a queue of tickets, they have a seat with the business: embedded with marketing, HR, or legal, understanding the strategy well enough to spot automation the business hasn't thought to ask for. More impact. Less backlog. Fewer fire drills. Say that plainly, then show it with one Guardian who has made the move.
Then change what gets rewarded. Integration teams value deployed integrations above everything; specs take a back seat and sometimes don't get written. Reverse that. The spec and its acceptance criteria rank above the deployed integration, which can be regenerated. That only sticks if specs count in performance reviews. Telling people specs matter isn't enough.
Integration adds a third type of Guardian. They're on call for a revenue-critical flow that breaks at 2 a.m., and if a coding agent built it in a colleague’s one-off session, they have no memory of how it fits together.
It's a fair objection, and not a new one: on-call engineers have always debugged code they didn't write, or wrote so long ago they forgot it. Now it’s another compelling reason for taking the spec-driven approach: they’ll have more context than they've ever had at that hour. The spec says what the flow should do and why each choice was made. That beats reading someone else's code.
Ask each Guardian what would have to be true before they'd let an agent build an integration.
Give each what they asked for, and start small. Don't ask any of them to let an agent build a new, high-stakes integration first.
Bessemer draws a line between vibe coding, where you accept whatever comes back, and agentic engineering, where you keep design and architecture in your own hands.
That line has a name: spec-driven design. The integration engineer or architect works out and approves the design before anything is built. The human's highest-value contribution stops being the flow itself. It becomes deciding how the work should be decomposed, stating what the correct output looks like, and encoding what should happen when something fails.
A veteran might say they can still build it better by hand. Often true, and beside the point. Expertise spent on one implementation decays when the system changes. The same expertise written as acceptance criteria applies to every future implementation, including the ones built after the expert moves on.
Bessemer downplays specs, saying “the beta is the spec.” This is one place where our opinion differs, at least in the context of enterprise integrations. Skipping the spec trades insurance for speed. Without one, the code is the only record of what a system is supposed to do. That’s fine until something breaks. In software, you can patch a bug. Integration can’t make that trade. A workflow that duplicates payments for an hour leaves records in a partner’s ledger that you can correct but never delete, and someone in finance spends the week reconciling them.
The spec also serves the team long term. It guides every redeployment, and when the integration breaks, it tells the engineer (or the agent) what the connection was supposed to do and why the business needed it.
A few things are true about agentic integration that nobody says loudly enough:
Agents don’t change who is accountable for an integration. They change how much one person can hold. Owning an integration has always meant someone who understands it, is on call for it, notices drift, and answers when it breaks, which is why integration capacity kept scaling with headcount.
Accountability stays with people, but integration agents can let one person's accountability cover more ground. When each major project and workstream has its own agent that continuously carries specs, history, and failure modes, integration engineers can spend less time babysitting workflows.
Customers tell us that on some integration teams, one or two engineers know each project or discipline. Onboarding others takes time and effort the team can’t spare when something breaks.
When an agent holds the context for a project, a junior engineer or a senior from another discipline can ask it questions. The agent supplies information, sources, and analysis. The newcomer drafts fixes for lower-priority problems while the primary engineer applies the most urgent one. The primary engineer then accepts, adjusts, or rejects the drafts.
The job starts to look like a portfolio owner's: defining outcomes, governing behavior, and managing by exception. A three-person integration team told us that arrangement would let them absorb work they now route to outside tools and vendors. The team’s leader told us that it would give the team much-needed flexibility.
Integration teams need a skill they didn’t have a couple of years ago: judging which steps in a workflow should be deterministic and which should be agentic.
A deterministic pipeline is predictable, cheap, and auditable. An agentic step can reason about an unexpected input, reconcile ambiguous records, or perform preliminary analysis. That value is real, and so is the risk: non-deterministic reasoning at runtime means the same input can produce different outputs. It also adds latency and removes any chance to review a decision before it's made.
The skill is introducing reasoning judiciously, where the value is worth the risk: unstructured inputs, and in-flight judgment too complex for rules. Everything that should happen the same way every time stays a plain pipeline. The agents that watch production and propose fixes sit beside the transaction path, not inside it, and they get narrow, well-scoped jobs. Teams that learn this well, and guide their integration agents to follow suit, will spend less, ship faster, and sleep better.
We explore the audit-trail and cost-predictability side of this in "Like Almost Everything in Technology, AI Is Not an All-or-Nothing Issue."
Not everyone you need to convert works for you. Much integration delivery runs through systems integrators and staff-augmentation firms. In a 2025 Gartner survey, only 14% of enterprises planned to handle their AI work mainly with internal resources.
A provider that bills by the hour earns less as agents cut delivery effort. They’re disincentivized to improve their own efficiency. One that bills by integrations under management earns more as they become more efficient. Know which contracts you hold before you plan. An integration consultant told us he expects agents to cut a five-day build to two, and that his peers will have to come on board because the change is coming either way. Where you can, move time-and-materials work to outcome-based terms at renewal. IDC expects 30% of IT services contracts to be outcome-based by 2029.
Bessemer's third finding is the one that should worry every CIO. Companies that built the foundation and converted their people still stalled near a 50% gain.
Individuals coding faster with AI didn't become organizational throughput. Their code hit other bottlenecks. In integration, we see a similar reality: AI can build integration code, but only as fast as the org can define what to build.
Today, discovery and design are often the most time-intensive stages of the integration lifecycle. Requirements gathering means enduring weeks of back-and-forth with business stakeholders and business analysts about not just goals, but nuanced fields, rules, and exceptions. Meetings, email threads, stops and starts. Mistranslations and mismatched expectations about what information is needed and when.
One developer we spoke with traced a year of rework to a project that was "ill defined and ill conceived out of the gate." The same engineer said his company's existing approach to gathering business requirements missed the mark: it didn't cover how particular vendors handled data.
Putting a generalized LLM at the end of that chain adds one more translator, and not a better one. A 2025 study put a generalist LLM’s odds of correctly inferring an unstated requirement at 41%, and those guesses were twice as likely to break when the model or prompt changed.
Three things that ease the bottleneck:
As Bessemer anticipates software engineering orgs flattening, it puts four “Chiefs of” over the organization: Architecture, Product, Design, and Security. They supervise what agents can't see for themselves, such as consistency across projects and drift toward whatever library is most popular. One startup in their study lost about $500,000 in billing from an internal app built without an architecture review. These Chiefs will also oversee integration agents.
Within integration the ideal state is for one “full stack” integration agent to deeply specialize in the project at hand and draw on compounding organizational knowledge of the estate and patterns.
The “full stack” integration expertise covers five people and four handoffs.
A general-purpose coding agent can’t play any of these roles well without being taught, and it can't succeed at integration until it's specialized in all five. From there, it works alongside humans whose roles shift to advising and approving.
With agentic integration, there's less sub-specialization within integration teams. When one specialized agent covers design, architecture, build, test, and operations, the queue between those roles disappears. The engineer’s job gets wider. One person can follow an integration from design through operations instead of handing it off at every step. Most integration teams already have more requests than they can handle. With agents, the same team can say yes to more of them.
We also see the bar rise across the team. A junior engineer learns by watching the decisions an integration agent makes, and gets guidance on the tradeoff decisions that require their human judgement. A senior integration expert has an always-on thought partner to debate alternatives, spar on priorities, and spot optimizations that apply across the estate.
Bessemer's playbook notes a ratio that inverts once engineering stops being the bottleneck: historically, about one product manager for every six engineers. Integration has its own version.
Today, a few architects set standards for many engineers who build and maintain workflows. As agents take on the building, engineers on your current roster level up to architects.
They build alongside agents, see every question the agent flags and learn which decisions it can't make alone. Deciding which answers apply to one integration and which apply everywhere is architecture work, and it takes practice and budgeted time. A forward-deployed engineer or an internal champion speeds it up.
The Architect role also changes what your standards documents are for. Long ignored, they stop being a wiki page a contractor skims. They become the context agents base decisions on at scale.
A principal software engineer told us his team had started storing technical standards in Confluence and exposing them to agents through MCP. Expect similar practices to spread.
Integration requests from AI teams are different in kind from those made by business stakeholders. A business integration is built once and runs deterministically under stable, reviewed conditions. An AI team's agent calls into the integration layer at unpredictable times with unscripted behavior.
This creates risks that AI teams and integration teams should reduce by working together to share skills. Integration teams have no framework yet for evaluating non-deterministic callers. AI teams often have no exposure to why a retry against a ledger can be catastrophic. Combining strengths minimizes blind spots and creates better outcomes.
Collaboration can be challenging when these teams report to different leaders, which is common. In Deloitte's 2026 survey of 662 senior technology leaders, 71% said their organization has five or more C-suite technology leaders. In a separate 2025 Deloitte survey, teams that worked across business units were 30% more likely to report significant gains from AI. Not every organization can redraw its org chart, but those who can may find value in putting AI and integration under the same umbrella.
Restructuring, acquiring, divesting, entering a market: each gets discussed in the boardroom as strategy and executed on the ground as integration. Deloitte's analysis of thirty M&A transactions found IT drove more than half the value a deal captured. It's a small sample, but it suggests a deal's value shows up at the integration layer, whatever the memo credits.
A company with a verified map of its integration estate reconciles two estates in weeks. One that has to send people into each system first measures the same work in quarters.
The payoff shows up in small changes, too. One of our customers learned, mid-build, that his EDI platform was deprecating the call his workflow used to mark transactions as processed. His memory of the estate told him other workflows used the same call, so he fixed those before they broke. He told us he'd like an agent to fix every workflow that uses it. That only works if something already lists every workflow that touches the call and what each one is supposed to do.
This section is for Bessemer's original reader, the engineering leader building an AI engineering function. Most of what your teams build with coding agents will touch enterprise systems or data. That's integration. You can let generic coding agents take a run at it, or you can give your coding agents integration-agent teammates that know how it's done right.
The practical ask is small. Bring the integration team into the AI Engineering Ops conversation now, before the coding agents are waiting on them.
Bessemer sorts its readers into three groups: the AI-pilled who are past the turn, the cautious movers nearing it, and the holdouts who still require a human review on every change. Their line is worth repeating: "Timing created the lead. Operating choices set the slope."
Most integration teams are holdouts today, and for defensible reasons. They touch the systems where mistakes are expensive, and they carry the legacy nobody else wants. But the same facts make integration teams the ones that can change slope fastest. Spec-driven, build-time AI with human approval fits the way integration already has to work. The late mover can still win here.
The close of The Agentic Awakening tells readers to “Read the clock. Then read the slope.” Some organizations started their shift to agents earlier than others, but the slope matters more than the start. Integration teams can sharpen that slope.
Agents are only as useful as the systems they can reach. Most of those systems live outside your walls. Integration teams that build safe, governed fast lanes across that last mile will take their companies further than any new LLM release. Autonomy in integration is earned one domain at a time. The teams that start earning it now won’t be catching up for long.
Peter Kreslins
Peter believes in the power of a digital world. He is living out his passion for technology — especially elegant software architecture — as CTO and co-founder of Digibee, where he is working with a team of leading developers to reimagine the way companies connect and launch digital services. Peter’s industry experience includes stints at Zup Innovation and CA Technologies. Peter received his Bachelor in Computer Science at the University of Sao Paulo in Brazil.
