The Pressure to Rebuild Versus the Cost of Rebuilding
Product leaders frequently propose rebuilding existing products to add AI capabilities. Engineering leaders frequently push back because rebuilds rarely deliver value commensurate with cost. The compromise that produces actual AI capability in shipping products is the AI integration surface: a specific architectural pattern that adds AI to an existing product without requiring a rewrite of the product.
KPMG's 2024 enterprise product survey found 78 percent of AI capabilities shipping in 2024-2025 reached production through integration patterns rather than through product rebuilds (KPMG, "AI in Control 2024 Survey"). The integration patterns delivered capability faster, at lower risk, and with operational characteristics the enterprise could absorb.
If your roadmap conversation is currently positioned as rebuild-or-no-AI, the false dichotomy is the problem. Four integration surfaces give product teams real options.
The Four Integration Surfaces
Four integration surfaces describe how AI capability connects to an existing product. Each one fits different product architectures and produces different user experience characteristics.
The first surface is the inline assistance pattern. AI capability appears as an in-product assistant or sidebar that operates alongside the existing product UI. The user can engage with AI when they want and ignore it when they do not. The existing product flow is unchanged. The AI's access to the product's data and actions is mediated through a clean API.
The second surface is the augmentation pattern. AI capability augments specific existing features without replacing them. The existing feature still works as it always did. The augmented version offers additional capability that the user can opt into. Smart suggestions in form fields, automatic summarization on top of existing detail views, AI explanations of existing data visualizations. The existing feature is the base; the AI is the layer above.
The third surface is the workflow extension pattern. AI capability extends existing workflows to handle cases that were previously manual or escalated. The workflow's automated portion stays. The AI handles cases that the existing automation could not. Customer support agents that handle tier-zero requests before escalating to humans, document processors that handle straightforward cases before routing edge cases to specialists.
The fourth surface is the sidecar pattern. AI capability runs alongside the product as a separate service that consumes the product's data and offers AI-powered features the product itself does not have. Analytics products that add AI-generated insights, monitoring tools that add AI-powered anomaly detection, search products that add AI-powered ranking. The sidecar accesses the product's data through APIs or replication and offers its capability through its own interfaces.
A workload assigned to the wrong surface produces friction. A workload assigned to the right surface integrates cleanly within the product's existing architecture.
The Engineering Investment Each Surface Requires
The surfaces have different engineering profiles that affect feasibility.
Inline assistance requires the existing product to have or grow an API surface that the AI assistant can use. For products built recently with API-first architecture, this is straightforward. For older products, the API work may be the larger investment than the AI work itself.
Augmentation requires identifying specific features where AI adds value and building the augmentation as an addition to those features. The investment is per-feature rather than systemic, which means the work can be incremental and prioritized.
Workflow extension requires the existing automation to have observable handoff points where AI can be inserted. Workflows with clean handoff are easy to extend. Workflows where the handoff is implicit or undocumented are harder.
Sidecar requires data access from the product to the AI service, which can be through APIs, replication, or events. The architectural separation makes the sidecar's failure modes independent of the product's, which is operationally useful but adds coordination complexity.
Most enterprises use multiple surfaces across their product portfolio rather than picking one. The surface selection happens per-product or per-feature, driven by product architecture and the specific AI capability being added.
What Each Surface Looks Like in Production
Inline assistance shows up in CRM products where AI assistants help with email drafting, lead summarization, and meeting preparation. The user can invoke the assistant or work without it. Successful examples include Salesforce Einstein, HubSpot Breeze, and similar in-product AI capabilities.
Augmentation shows up in productivity tools where AI extends existing features: smart compose in email, formula suggestions in spreadsheets, design suggestions in slide tools. The existing feature works; the augmentation makes it more efficient. The pattern is now standard in mainstream productivity software.
Workflow extension shows up in customer support and operational workflows. Tier-zero AI handlers, intelligent triage, AI-assisted resolution. The pattern that Klarna's 2024 deployment popularized in customer support reduces volume on existing escalation paths without replacing them.
Sidecar shows up in analytics and business intelligence tools. AI summarization of dashboards, AI-generated insights on top of existing data, AI-powered anomaly detection running parallel to existing monitoring. The sidecar adds capability without modifying the underlying data infrastructure.
The patterns are visible across multiple software categories. Each one fits specific situations rather than being universal.
The Operational Realities the Surfaces Hide
Each integration surface has operational realities that are easy to underestimate during initial design.
Inline assistance has to handle the inconsistency between AI behavior and product behavior. When the user uses the AI to do something the product itself does not directly support, the user may be confused. The integration design has to make the AI's scope clear.
Augmentation has to handle reliability inconsistency. The existing feature has reliability characteristics the user knows. The augmented version may have different characteristics (slower, occasionally wrong). The design has to set expectations or hide the inconsistency.
Workflow extension has to handle the boundary between AI-handled and human-handled cases. Customers transitioning from AI to human experience inconsistency. The boundary design is what makes the experience coherent.
Sidecar has to handle data consistency. The sidecar's view of the product's data has some latency. The sidecar's outputs may reference state that has changed in the product. The design has to handle the asynchrony.
These realities are part of the integration work. Teams that ignore them produce integrations that feel rough to users. Teams that design for them produce integrations that feel integrated.
What Logiciel Does Here
Logiciel works with product engineering teams adding AI capability to existing products where rebuilds are not feasible. The work is typically structured around surface selection followed by architecture and implementation for the chosen surface.
The Software Architecture in the AI Era framework covers the inference-boundary design that integration surfaces sit within. The AI Integration Legacy Systems framework covers the five integration modes for the legacy-side concerns.
A 30-minute working session is enough to map your candidate AI capability against the four surfaces.
Frequently Asked Questions
How do I choose between the four surfaces?
Match the surface to the AI capability and the existing product's architecture. Conversational AI usually fits inline assistance. Per-feature improvements fit augmentation. Workflow automation fits workflow extension. Analytical or insights work fits sidecar.
Can a single product use multiple surfaces?
Yes, and most do. A single product may have inline assistance for some use cases, augmentation in specific features, and sidecar analytics. The surfaces are not mutually exclusive at the product level; they apply to specific AI capabilities within the product.
What is the right team for AI integration work?
Existing product engineers paired with AI engineers. Pure AI engineering teams without product context often build technically interesting integrations that miss the product's actual use cases. Pure product engineers without AI fluency often build integrations that work poorly. The pairing is what works.
How do I handle the data access required for AI integration?
Through explicit data contracts. The AI capability accesses defined product data through defined interfaces. Implicit data access through database reads or event streams produces brittle integrations that break when the product evolves. The contract is what keeps the integration durable.
What is the typical timeline for AI integration into an existing product?
Three to nine months for the first integration depending on surface and product complexity. Inline assistance is usually faster than sidecar because the architectural separation in sidecar requires more upfront work. Subsequent integrations in the same product are typically faster than the first. Sources: - KPMG, "AI in Control 2024 Survey" - Klarna AI Assistant press release, 2024
