10decodersYour application already works. It just doesn't think yet.
You have a custom application or a product in production, with real users, real data and a roadmap that already has more on it than the team can ship. Adding AI shouldn't mean pausing that roadmap for a rebuild. We run a workshop against your actual codebase, data model and integration surface, hand you an augmentation roadmap you own, then implement it one sequenced step at a time.
Trusted by leading enterprises and healthcare teams
Most AI programmes don't fail on the model. They fail on the join.
The pilots that stall are the ones built beside the business, in a notebook or a standalone tool, with no path back into the workflow people already use. Augmentation inverts that. It starts from software that already has users, already holds the data and is already on the critical path — so the only thing left to prove is whether the AI helps.
of enterprise generative AI pilots produced no measurable impact on profit and loss, across 300 public deployments studied.
MIT Project NANDA — The GenAI Divide: State of AI in Business, 2025of enterprise-grade AI tools evaluated made it all the way to production. Most were rejected for brittle workflow fit, not model quality.
MIT Project NANDA, 2025 — 60% evaluated, 20% piloted, 5% deployedof AI projects are forecast to be abandoned through 2026 where the organisation has not made its data AI-ready first.
Gartner forecast, as widely reportedThe blocker is rarely "which model."
Six situations come up in almost every conversation with a team that owns a working application and a board asking about AI.
Forty ideas, no order
Every department has an AI suggestion and all of them sound reasonable. Nobody can say which one is worth building first, so the list gets re-discussed each quarter instead of shipped.
The roadmap is already full
Your engineers know the product better than anyone, which is exactly why they're committed to the next two releases. Pulling them onto an AI experiment costs you the releases and usually still doesn't ship the AI.
The data is there, but not reachable
It's spread across an operational database, a warehouse, a document store and three integrations. Nobody has assembled the view a model would actually need, and nobody wants to be the one to say so.
The prototype won't survive review
Something works in a sandbox. Then security asks where the data goes, legal asks how a decision is explained, and support asks who answers when it's wrong. The demo has no answers, so it stays a demo.
Customers are asking, and so are competitors' customers
For software vendors this arrives as a renewal question and an RFP line item. The pressure is to announce something quickly, which is how teams end up shipping a chat box nobody uses.
The valuable logic is locked in an old application
PowerBuilder, Oracle Forms, MS Access, a mainframe batch job. The business rules that matter are in there, and there's no service boundary to attach anything to.
Augmentation happens at seams, not in a rewrite.
Your application already has natural attachment points. The workshop's technical job is to find which of them your system actually exposes today, and which would need work first.
Nothing above requires the application beneath it to be rebuilt. Where a seam doesn't exist yet — typically an API facade over a legacy screen, or a read model the warehouse never exposed — that becomes a line item on the roadmap with its own cost and sequence, visible before you commit.
Six augmentation patterns we build
Knowledge retrieval
Answers grounded in your own records, policies, tickets and documentation, with citations back to the source record — so the answer can be checked rather than trusted.
- Chunking and indexing tuned to your content, not a default
- Role-based access carried through to retrieval results
- Freshness strategy so the index tracks the system of record
In-product copilot
An assistant inside the screens your users already work in, scoped to the task in front of them rather than a general chat window bolted to a corner of the page.
- Context passed from the current record and user permissions
- Suggested actions the user confirms, with an audit entry
- Clear states for processing, low confidence and refusal
Document and media intelligence
The paperwork your workflow runs on — forms, statements, claims, contracts, scans, video — turned into structured fields with confidence scores and an exception queue.
- Extraction from complex, multi-page and low-quality sources
- Validation and reconciliation across a whole file
- Human review in the flow, never silent auto-approval
Decision support and scoring
Ranking, triage, eligibility, risk and prioritisation delivered as a service your application calls — with the reasoning, the inputs and the version recorded alongside the result.
- Thresholds set with your team, not inherited from a demo
- Override captured as a labelled signal, not lost
- Shadow mode before anything influences a live decision
Agentic workflow
Multi-step work that currently moves between systems because a person carries it — validate, look up, compare, draft, route, escalate — run as a supervised agent with gates where risk sits.
- Tool access scoped per step, with least privilege
- Approval gates only where exposure justifies them
- Full trace of every step, tool call and hand-back
Conversational and voice channels
Support, intake and status handled on the channel the customer already uses, connected to the same business logic your staff use, so the two never diverge.
- One intent and policy layer across chat, email and voice
- Escalation to a human with the full context attached
- Containment and deflection measured per intent, not overall
Five horizons. You can stop after any of them.
The numbering is a real sequence, not a diagram. Each horizon depends on the one before it, and each one ends with something you can hold — a document, a working feature, an operating capability. Most organisations we meet are somewhere between Horizon 0 and Horizon 1.
Augmentation workshop
Read the system as it is. Inventory candidate use cases, test them against value and readiness, assess whether the data supports them, and sequence what survives.
First augmentation, live
One use case, contained scope, real data, real environment. Built with the evaluation harness and audit trail from the first sprint rather than retrofitted for review.
The layer, not the feature
Turn what the pilot proved into shared plumbing: retrieval and context services, model routing, prompt and version control, access policy, observability, cost controls.
Across the workflow
The remaining roadmap delivered in sequence, each augmentation reusing the foundation. Release cadence, evaluation gates and rollback treated as normal engineering.
Run it, and hand it over
Drift monitoring, evaluation regression, model swaps as the market moves, cost per outcome tracked. Knowledge transfer to your team, or a pod that keeps operating it with you.
A working session, not a use-case brainstorm.
Most AI workshops on the market are ninety minutes on a whiteboard and a prioritisation grid at the end. Ours runs against your repository, your schema and your integration inventory, because the interesting constraints are in there — and a roadmap that ignores them is a wish list.
| When | Session | What comes out of it |
|---|---|---|
| Pre-work | System readRepository access, schema export, integration inventory and a walkthrough with two of your engineers. | A map of the application drawn by us and corrected by you — before anyone spends a day in a room. |
| Day 1 AM | Where the work actually hurtsSession with the people who run the workflow, not only the people who sponsor it. Volume, cycle time, error and rework mapped per step. | A ranked list of the workflow steps that cost you the most, with numbers attached. |
| Day 1 PM | Candidate augmentationsEach painful step tested against the six patterns. Anything that fails on data availability or explainability is discarded openly rather than parked. | A long list, and — more usefully — a written record of what we ruled out and why. |
| Day 2 AM | Data readinessWhat your models could see today, what is trapped, what is unlabelled, what is too dirty to be useful yet, and what carries residency or consent constraints. | A readiness assessment per candidate, with the remediation each one needs. |
| Day 2 PM | Architecture and seamsWhere each augmentation attaches, what has to be built to expose the seam, deployment topology, model policy and cost envelope per call. | A target architecture and a decision record for the choices that constrain everything after. |
| Day 3 AM | Scoring and sequencingEvery candidate scored on business value, data readiness, engineering effort, risk exposure and change impact on your users. | The scored backlog, and a defensible answer to "why this one first." |
| Day 3 PM | The first build, scopedHorizon 1 defined tightly enough to estimate: scope, success metrics agreed in advance, access needed, review path and who signs off. | A pilot definition your team could hand to any competent partner, including us. |
Four artefacts you keep
- Augmentation backlog — every candidate scored on value, readiness, effort and risk
- Target architecture — where AI attaches, what has to be built to let it
- Data readiness assessment — what your models can and cannot see today
- Sequenced roadmap — five horizons, with Horizon 1 scoped to build
Yours whether or not you continue with us. No part of it is written to be unusable by another partner.
Who needs to be in the room
- The engineer who knows why the system is the way it is
- Whoever owns the workflow day to day, not only the sponsor
- Product, for anything customer-facing
- Security or compliance, for half a day — early, not at the end
- The budget holder, for the final session
Runs on site or remote. Remote works; on site tends to surface the awkward constraints faster.
Each step ends with a gate you can stop at.
The first augmentation is deliberately narrow. The point isn't the feature — it's proving the join between AI and your system works end to end, including the unglamorous parts: access, evaluation, release, support and cost.
Access and ground truth
Environments, credentials and data access agreed and working. A graded test set built from real cases with your team's answers as the benchmark — before anything is built against it.
Thin slice, end to end
The narrowest version that touches every layer — seam, retrieval or model call, application response, logging. Ugly on purpose. It exists to find the integration problems while they are cheap.
Quality, until it holds
Retrieval tuning, prompt and context engineering, model selection against your test set, threshold setting, failure-mode analysis. Every change measured rather than eyeballed.
Shadow run
The augmentation runs against live traffic without affecting anything. Your team compares its output with what actually happened, and the disagreements teach you more than the matches.
Controlled release
Live for a defined cohort behind a flag, with rollback rehearsed, support briefed, an exception path staffed and per-call cost visible from day one.
Measure and decide
Result read against the numbers agreed before the build. Then an honest recommendation: scale it, change it, or stop — and we will say stop when the evidence says stop.
Working software in the first sprint, not a blank canvas.
Model-agnostic by design. No hyperscaler subsidy steering the architecture, and nothing that ties your workflow to one vendor's roadmap.
CheiAI
The orchestration layer the augmentation sits on: model routing, context assembly, agent framework, evaluation harness, access control and audit trail — in place from sprint one rather than added for the compliance review.
- Model-agnostic routing with fallback and cost policy
- Rapid Agent Builder for multi-step workflow agents
- Prompt and version control with reproducible configuration
DocuFindr
Document intelligence for the paperwork inside your workflow. Fields, tables and clauses come out as structured data with confidence scoring and an exception queue, so nothing auto-approves quietly.
- Extraction from complex, multi-page documents
- Compare, reconcile and validate across a whole file
- Human review built into the flow, not bolted on
VuFindr
Computer vision and video analytics where the signal is visual — inspection, monitoring, identity, condition and event detection — with the same confidence and exception model as the document side.
- Detection and classification on your own imagery
- Event and condition monitoring from video streams
- Edge or cloud deployment depending on latency and policy
Integration and modernization accelerators
Where the seam doesn't exist yet: vortexFlow for connector-led integration, and migration accelerators for PowerBuilder, Oracle Forms, MS Access and mainframe applications when business logic has to be freed before AI can reach it.
- Pre-built connectors for partners, rails and core systems
- Screen-by-screen migration with business logic preserved
- Agent-accelerated inventory, mapping and test generation
Built to survive the review, not just the demo.
- Your data stays where your policy saysDeployment into your cloud account, your VPC or a fully isolated environment with no external model calls. Model choice follows the data policy, not the other way round.
- Evaluation before release, and afterA graded test set, a threshold agreed in advance, and regression runs on every change. When quality moves, you find out from a dashboard rather than a customer.
- Explainable by defaultEvery AI-influenced output carries its inputs, the retrieved sources, the model and prompt version, and the reviewer. Producing the trail is part of the build.
- Human in the loop where the risk isApproval gates sit at the points carrying regulatory, financial or reputational exposure — and nowhere else, so the automation still earns its keep.
- Cost visible per outcomeToken, inference and infrastructure cost tracked against the unit of work the augmentation performs, so the business case survives contact with the invoice.
- Delivery discipline you can point atRACI on every account, Definition of Ready and Definition of Done agreed up front, stable pods rather than a rotating bench.
Where we are not the right answer.
Four situations where we will tell you to spend the money elsewhere. Hearing this in week one is cheaper than discovering it in month six.
You need an announcement, not a capability
If the deadline is a launch date and the requirement is that AI appears somewhere, a smaller agency will get you there faster and cheaper. We build things intended to still be running next year.
A packaged product already does it well
If your need is met by an off-the-shelf tool that already integrates with your stack, buy it. We will say so in the workshop, and we would rather lose the build than sell you a worse version of something you can license.
Frontier research, not applied engineering
Novel model architecture or original research is not our practice. We engineer applied systems on top of models that already exist, into software that already runs.
The data isn't there yet, and you don't want to hear it
Some augmentations need data work first. If the assessment says so and the appetite is to build anyway, we are the wrong partner — that programme fails, and we would rather not be attached to it.
No one internally owns the workflow
Augmentation changes how people work. Without a named owner on your side who can decide what "good" looks like, the pilot has nobody to hand it to, and it stalls after the demo.
You want a resource, not an outcome
If the requirement is bodies against a backlog, our GCC and dedicated pod model is the better route. This service is scoped around an outcome and measured against it.
AI added to systems that were already running.
Three engagements where the brief was augmentation rather than replacement. Client names withheld under NDA — available on a call under mutual disclosure.
Credit limit review, automated
Credit limit increases were handled by hand across several systems. We added a workflow agent that validates the customer, pulls the bureau score, checks repayment eligibility and auto-approves the clear cases — with every step logged. The underlying systems were untouched.
Recommendations for relationship managers
A global asset manager's client insight sat in disconnected custodial and CRM systems. We built the ingestion and portfolio analysis engine underneath, then personalised recommendation models on top — with explainable output so compliance could sign off.
AI decisioning inside an SBA lending platform
Document OCR, risk scoring and eligibility added into an existing origination workflow, with Salesforce carrying the process. Approvals and compliance checks moved from manual review to an automated pass with exceptions routed to humans.
Start where you actually are.
No fifty-page proposals. We meet your real maturity, prove value in a contained pilot, then scale what works.
Augmentation workshop
Run against your codebase, data and integration surface. Ends with a scored backlog, a target architecture, a data readiness assessment and a roadmap you own.
First augmentation
One use case, contained scope, real data. Six steps, six gates, measured against numbers you set before we started.
Foundation, rollout and operate
The shared augmentation layer, the rest of the roadmap in sequence, then ongoing AI operations — or handover to your team.
The pilot is paid, and the fee is credited in full against the programme that follows. If the numbers don't land, you keep a working assessment of your data and workflow, a roadmap you can take to anyone, and no obligation to continue.
Questions, answered.
What is AI augmentation, and how is it different from an AI project?
AI augmentation adds capability to software that already exists and already has users. The application keeps its data model, its integrations and its user base; AI attaches at defined seams — a retrieval layer, an in-product assistant, a document pipeline, a decision service, an agentic workflow. An AI project usually starts from a blank page and has to earn its users. Augmentation starts from a workflow that already has them, which is why it reaches production more often.
Do you need access to our source code?
For the workshop we need read access to the repository, the data model and the integration inventory, under NDA. If your policy doesn't permit external code access, we run the workshop against architecture documentation, schema exports and a screen-share walkthrough with your engineers. The output is less precise but still usable, and we will tell you which findings are lower confidence as a result.
What do we get out of the workshop?
Four artefacts: a scored augmentation backlog of candidate use cases ranked by value and readiness; a target architecture showing where AI attaches to your existing system; a data readiness assessment covering what your models can and cannot see today; and a sequenced roadmap with the first augmentation scoped tightly enough to build. You keep all four whether or not you continue with us.
Will this lock us into a particular model or cloud?
No. CheiAI, our orchestration layer, is model-agnostic by design and deploys into your cloud account, your VPC or a fully isolated environment. Model choice follows your data policy rather than a hyperscaler commitment, and the routing layer is built so a model can be swapped without touching the application.
Our application is old. Does it have to be modernized first?
Usually not, and treating modernization as a prerequisite is how augmentation programmes lose two years. AI can attach at the data layer or through an API facade while the legacy application keeps running. Where modernization genuinely is the blocker — business logic locked inside PowerBuilder or Oracle Forms screens with no accessible service boundary, for example — we will say so in the workshop, and we have migration accelerators for exactly that situation.
How do you keep AI output from embarrassing us in front of customers?
An evaluation harness is built before the feature ships, not after the first complaint. Every augmentation gets a graded test set, a confidence threshold, an exception path to a human, and logging that captures the inputs, the model version and the reviewer. Where the risk is customer-facing or regulated, the default is assistive output with a human confirming, not silent automation.
We're a software vendor, not an enterprise IT team. Does this work for us?
Yes, and the economics are usually better. For a software vendor the augmentation lands in a product used by every customer, so one build amortises across the whole base. The workshop changes shape slightly — more time on multi-tenant data isolation, per-customer context, unit economics per call, and how the capability gets packaged and priced.
How long before something is actually in production?
The workshop runs in a week including pre-work. The first augmentation is scoped to reach a real environment on real data rather than a demo build. Timelines depend on data access and your release process, which is exactly why the workshop assesses both before anyone commits to a date.
What does a first engagement look like commercially?
The augmentation workshop, then a paid pilot on one augmentation. The pilot fee is credited in full against the programme that follows. If the numbers don't justify going further, you keep the roadmap, the assessment and the working pilot, and there's no obligation to continue.
