Decision intelligence · Industrial · Supply chain
Coordinated decision intelligence — above the systems you already run.
The A2go Decision Intelligence Platform (ADIP) coordinates across your existing stack instead of centralizing it into another platform. Coordinated, not centralized.
- ADIP — one governed decision layer, built natively on Databricks, above any ERP, WMS, or planning system.
- ADOE makes your existing data AI-ready without moving it, governed through Unity Catalog end to end.
- Approval-ready recommendations. Coordinated supply chain agents produce calls your planners review, override, and approve.
- The Judgment Layer encodes how your organization decides and compounds with every approval.
- Coordinated, not centralized. Deployed without migration; your stack stays where it is.
Category: Supply chain decision intelligence · Foundation: Built natively on Databricks · Model: Layered, not centralized
Definition
What supply chain decision intelligence is.
Decision intelligence is the layer that turns what your systems already know into a specific, governed, approval-ready course of action — and coordinates that action across every system it touches. It is not a place data goes. It is the reasoning that sits between the data and the person accountable for the call.
In one sentence. ADIP — the A2go Decision Intelligence Platform — is a governed decision intelligence layer that reads from the systems a manufacturer or distributor already runs, coordinates a set of purpose-built supply chain agents across them, applies that company's own decision logic, and writes approved actions back into the systems of record — without migration or replacement.
Adjacent categories, and how this differs
| Category | What it does well | Where it stops |
|---|---|---|
| Data platforms and lakes | Store, govern, and serve enterprise data at scale. | They deliver data. They do not decide anything, and they do not act. |
| BI and analytics | Show what happened and, increasingly, what is likely to happen. | An insight still needs a human to convert it into a decision and an action. |
| Advanced planning systems | Optimize within a plan, on a cycle, inside their own model of the business. | The reasoning stays inside one system's boundary and one planning cadence. |
| Workflow and process automation | Execute a defined sequence reliably and repeatedly. | It runs rules somebody wrote. It does not weigh a tradeoff that was never encoded. |
| Assistants and generative interfaces | Answer questions and draft in natural language, fast. | They have no memory of how your company decides, and no authority to act. |
| Decision intelligence | Coordinates a decision across systems, with the reasoning and the tradeoffs attached. | It does not replace any of the above. It sits above them and uses all of them. |
Learn more
- ReferenceThe Decision Library — The supply chain decisions in scope, by pillar, with the metric each one moves.
- FAQWhere ERP-native AI stops — What the AI inside existing systems does well, and where it runs out of room.
- On this pageCoordinated vs. centralized — The architectural choice underneath the category, and what each one costs.
Architecture
Coordinated, not centralized.
Every vendor in this space is now talking about agents, orchestration, and intelligence that compounds. The real distinction is where the intelligence compounds, and what architecture is required to make that happen.
CENTRALIZED — Intelligence compounds inside the vendor's platform
- Customers migrate, conform, or centralize planning inside a proprietary environment
- The learning accrues to the platform's own model of the business
- Value arrives after the program lands, not before
- Leaving means unwinding the process, not just the software
COORDINATED — Intelligence compounds across the systems you run
- The layer reads from source systems and writes back into them
- The learning accrues to your decision logic, not to a vendor's model
- Value arrives one decision at a time, starting in weeks
- Open formats and unchanged sources mean the exit is real
A2go creates compounding intelligence across the enterprise without requiring companies to migrate into a proprietary planning platform. The intelligence compounds because it is connected to real operating decisions across ERP, CRM, planning, inventory, production, logistics, and customer service — not because everything was moved into one vendor's system.
Learn more
- Deep diveInside ADIP — The three layers of the platform and how they fit together.
ADIP
The A2go Decision Intelligence Platform.
ADIP is the umbrella. Three layers, read bottom to top, with human oversight running across all of them. Each layer has a distinct job, and each one is separately describable — which matters when the question is what exactly you are buying.
- — Human oversight — Runs across every layer. Operators approve, override, and govern; every override becomes a signal the system learns from.
- 03 · The Judgment Layer — Company decision memory. The priorities, rules, and guardrails that never made it into any system, encoded and compounding with every approval.
- 02 · Coordinated agents — Purpose-built supply chain agents that reason across data, rules, tradeoffs, and constraints to produce explainable, approval-ready recommendations.
- 01 · ADOE — The data foundation. A streaming, AI-native orchestration layer above the source systems, built natively on Databricks.
- 00 · Your existing stack — Unchanged. ERP · WMS · OMS · planning · commerce · execution. Nothing is migrated, and nothing is replaced.
Agent coverage
Agents are organized across four pillars, and every agent is tied to a measurable financial metric. Value is attributed to the coordinated system rather than to any single agent, because coordination is what produces it.
- Forecasting & Planning. Demand sensing, supplier and distributor forecasting, full-horizon forecast and planning.
- Operational Planning. S&OP and master production scheduling optimization, purchase order excellence, safety stock optimization.
- Supply & Inventory Optimization. ABC classification, slow-moving inventory, multi-echelon inventory optimization, VMI opportunity, supplier reliability.
- OTIF Optimization. Capable-to-promise, unexpected customer order, promise jeopardy, revenue and OTIF optimization.
Learn more
- Deep diveADIP, layer by layer — Each layer defined, with what it takes in and what it produces.
- ReferenceThe Decision Library — Every decision in scope, by pillar, with the metric it moves.
ADOE
The A2go Data Orchestration Engine.
A streaming, AI-native data layer that sits above the systems a customer already runs and continuously delivers governed, AI-ready data to every agent above it — with no migration. It runs six functions continuously rather than as sequential batch stages.
- 01 · Ingestion — Connects to source systems, spreadsheets, supplier feeds, and external signals. Real-time, micro-batch, or scheduled.
- 02 · Enrichment — Reconciles entity definitions, aligns hierarchies, standardizes codes, and puts time series on one clock.
- 03 · Storage — Governed, open-format storage on the Lakehouse. Versioned, so historical states stay auditable.
- 04 · Streaming — A tailored data product per consumer — an agent, a model, a dashboard — not one flattened table for all of them.
- 05 · Consumption — Agents, models, and applications draw on demand through governed interfaces, with humans able to intervene.
- 06 · Monitor & govern — Watches for anomalies, schema drift, and upstream breaks; notifies, and where possible self-heals before decisions run on bad input.
The standing objection
"We already have a data lake."
ADOE works alongside it and generally makes it more valuable, turning static stores into live, agent-ready feeds. It reads from a lake, a warehouse, or a fabric on any vendor's platform through standard governed interfaces, and it does not require a finished master-data program before it delivers value — it reconciles across the definitions that exist today. It is portable by construction: open table formats, model-agnostic delivery, and source systems left unchanged. Remove ADOE and the infrastructure is exactly where it was.
Named on the page: Databricks · Snowflake · Azure Synapse · AWS Redshift · Google BigQuery · Cloudera · Delta Lake · Iceberg · Data fabric
Governance plane: Unity Catalog · Table formats: Delta · Iceberg-compatible · Model layer: provider-agnostic · First domain live in weeks
Learn more
- ExternalA2go on Databricks — The customer story Databricks published on the apps A2go runs on its platform.
Approval-ready recommendations
The output is a decision package, not an alert.
Coordinated agents produce calls your planners review, override, and approve. Every recommendation is a defined artifact with required fields, which is what makes it auditable as well as actionable.
- Judgment stays human. Full tradeoff visibility and override authority at every step. Overrides are first-class actions and are captured with their reasoning.
- Write-back is governed. Approved actions return to ERP, WMS, planning, and execution systems with lineage and audit intact.
- Automatic only where you grant it. As projected outcomes prove out, the customer decides which calls run without review — and can move that line back.
Required fields of a decision package
- Recommended action — The specific call, stated so it can be executed without interpretation.
- Trigger — The data and constraint that caused the recommendation to be produced.
- Alternatives — What else was considered, and what each one would have cost.
- Expected impact — The outcome the action is projected to produce, in the metric that matters.
- Rules applied — The company policies and guardrails that constrained the reasoning.
- Coordinated with — The other agents and domains whose answers were reconciled into this one.
- Audit record — Who approved or rejected it, when, and why — logged on every decision.
Learn more
- Deep diveAnatomy of a decision package — A worked example, field by field, as a planner would read it.
- ReferenceThe Decision Library — The decisions agents produce across all four pillars.
- FAQHow a call becomes automatic — The mechanism by which a reviewed call becomes an automatic one.
The Judgment Layer
The part of your business that never made it into software.
Your best planner knows which customer you protect when two orders compete, which supplier's lead time to distrust in August, and when the rule gets broken. None of that is in your ERP. It's in people, and it walks out at retirement. The Judgment Layer encodes it — and every approval and override makes it sharper.
| Stage | What happens |
|---|---|
| Traces (how it's captured) | Every decision your planners make is captured — including the ones they reject, override, escalate, and handle as exceptions. The why behind every yes and no. |
| Decision memory (where it goes) | Priorities under load, supplier and allocation rules, lead-time and SLA guardrails, escalation policy — accumulated into a memory unique to your company. |
| Governed decisions (how it's used) | The next recommendation reflects how you actually decide. Approved overrides become reusable playbooks, available across the next disruption. |
The loop: More usage → More traces → Sharper agents → Better decisions → (repeats, compounding every cycle)
STANDARD CASES · VOLUME — Build the baseline fast
- High-frequency, predictable scenarios
- Quick accuracy, early confidence
- Where adoption starts
EDGE CASES · DEPTH — Where the value actually is
- Exceptions, overrides, conflicts
- The calls that need real judgment
- Where your institutional knowledge is captured
Specific to you, retained by you. Your Judgment Layer carries your company's own decision logic — the approvals, the rejections, and the reasoning behind them. It is never shared across customers. Without it, AI is just automation; with it, expertise compounds instead of retiring. This is the piece no chatbot or generic assistant delivers.
Learn more
- Deep diveHow we capture tribal knowledge — Traces, decision memory, and the loop that compounds with every approval.
- FAQStandard cases vs. edge cases — Why the exceptions are where your institutional knowledge actually lives.
Coordinated, not centralized
Deployed without migration.
The deployment model follows from the architecture. Because nothing is centralized, nothing has to be moved first — which is what makes an incremental, reversible adoption path possible rather than aspirational.
- 01 · Rapid assessment — Map the source systems, identify the highest-value first decision, and scope an initial deployment. Days, not weeks.
- 02 · First domain live — One source environment, one decision, one measurable result — before any large commitment is made.
- 03 · Expansion on the customer's timeline — Additional sources and decisions activate as each earlier phase proves out. The customer controls pace, priority, and scope.
- 04 · Compounding, not a new project — Every approval strengthens the Judgment Layer, so the calls improve without another implementation cycle.
What the model rules out
These are structural consequences of layering rather than centralizing, which is why they hold across deployments rather than being negotiated per customer.
- No all-or-nothing commitment. There is no point at which the customer is committed to a phase they have not validated.
- No lock-in at any stage. Open formats, portable operations, source systems unchanged. Full ownership and full optionality throughout.
- No prerequisite programs. Master data, org design, and process standardization are supported over time rather than required up front.
Scope and fit
The facts, in one place.
For anyone building a shortlist, a briefing, or a comparison, this is the summary sheet.
- Category — Supply chain decision intelligence
- Platform — ADIP — the A2go Decision Intelligence Platform
- Architecture — Governed layer above existing systems. Coordinated, not centralized.
- Foundation — Built natively on Databricks; governance through Unity Catalog; open table formats
- Coverage — Purpose-built supply chain agents across forecasting and planning, operational planning, supply and inventory optimization, and OTIF optimization
- Layers over — Any ERP, planning or SCM system, WMS, OMS, CRM, MES, commerce platform, or data warehouse
- Who it serves — Manufacturers and distributors moving physical goods, where planning complexity comes from multiple sites, multiple ERPs, high SKU counts, or regulatory obligation
- Entry point — One decision, chosen with the customer — typically the highest-pain planning or promising decision
- Time to first value — First domain live in weeks
- What it replaces — Nothing. No migration, no system replacement, no prerequisite master-data program
- Not a fit — Businesses with no physical inventory, a single clean system with no planning complexity, or a data-warehouse project rather than a decision problem
Common questions
The questions that come up first.
Is this a replacement for our planning system?
No. ADIP layers above planning and every other system of record. The planning system keeps planning; ADIP coordinates the decision across it and everything else that holds part of the answer.
Do we need to move our data first?
No. ADOE reads from sources where they already sit, including a lake, warehouse, or fabric on another vendor's platform, and reconciles across the definitions that exist today.
How is this different from the AI already in our ERP?
Native AI reasons well inside the boundary of its own system. The decisions that cost the most span several systems, and no single vendor's AI sees across that boundary.
Does it act on its own?
Only where the customer grants it. Recommendations are approval-ready by default; a call becomes automatic when the customer decides it has proven out, and that decision is reversible.
What happens to our people's expertise?
It is captured rather than displaced. The Judgment Layer encodes how the company's planners actually decide, and every approval and override makes it sharper.
Is our decision logic shared with other customers?
No. Each customer's Judgment Layer carries their own approvals, rejections, and reasoning, and it is never shared across accounts.
How long before something measurable moves?
First domain live in weeks, measured against the baseline the customer brings. Expansion happens one decision at a time, on the customer's roadmap.
What if we want to remove it?
Source systems are unchanged and data stays in open formats throughout. Removing ADIP leaves the infrastructure exactly where it was before.
Start here
Bring us your worst decision of the month.
Not a platform evaluation. One working session on the decision that costs you the most today — where it stalls, what it's worth, and what a first deployment against it would look like on your existing systems.
What the session looks like
- You bring the decision and the people who make it
- We map where it stalls across your systems
- You leave with a scoped first domain and a timeline
- No migration proposal, no platform commitment