Supply chains rarely operate in neat, single-step workflows.
Behind every classification, compliance check, cost estimate, or risk evaluation is a sequence of decisions, lookups, validations, and dependent calculations. Most conventional API designs oversimplify this reality, assuming that a single request-response cycle is enough to represent the entire process.
Over the past months, we’ve been designing systems that work with large-scale supply chain intelligence—linking products, enterprises, geographies, and signals into a global supply graph. Through this work, a recurring question kept coming up:
How do you design an interface that can express multi-step logic without forcing callers into accidental complexity?
This question led us to explore a lightweight A2A (Agent-to-Agent) protocol — not as a multi-agent orchestration framework, but as a practical pattern for exposing modular, long-running, or multi-step capabilities as predictable components.
Below is a breakdown of the architectural reasoning behind it.
The Problem: Supply Chain Workflows Are Multi-Step by Nature
Many supply chain operations look simple from afar, but internally they unfold across multiple decisions or data layers. A few examples:
- classification steps that refine product descriptions into standardized codes
- compliance or tariff processes with exceptions, sub-rules, and country-specific logic
- multi-hop dependency exploration across suppliers, regions, or product layers
- geographic concentration checks requiring aggregation across many nodes
- structured intelligence gathering based on scattered open signals
Trying to represent these in a single synchronous API call introduces several issues:
- Long execution time
- Complex internal branching
- Difficult error reporting
- Opaque reasoning or outputs
- Hard-to-maintain monolithic endpoints
The challenge wasn’t performance—it was expressiveness.
We needed a way to expose complex analysis in a way that remained clean, predictable, and modular.
Why We Explored an A2A Pattern
Rather than building one large API that tries to handle everything, we started experimenting with exposing the system’s core capabilities as small, purpose-built units that each perform exactly one task.
Not full “agents” in the LLM sense.
Just modular components with clearly defined jobs.
Each unit:
- takes a well-defined input schema
- processes asynchronously (if needed)
- exposes a
run → status → resultlifecycle - returns structured, deterministic output
This simple pattern turned out to map surprisingly well to real supply chain workflows.
The A2A Lifecycle
The protocol revolves around three predictable operations:
1. run
Initiates a task with structured input.
{
"task_input": { ... },
"metadata": { ... }
}
Returns a task_id.
2. status
Allows the caller to check progress, especially for long-running or multi-step logic.
{
"task_id": "abc123",
"status": "PENDING"
}
3. result
Retrieves the final, structured output once complete.
{
"result": { ... },
"evidence": { ... }
}
This design keeps the interface predictable while allowing each unit to express as much internal logic as needed—validation, multi-step reasoning, dependency expansion, or risk calculations.
Why This Pattern Works Well in Supply Chain Systems
1. Mirrors Real Workflow Structure
Supply chain logic unfolds step-by-step.
The A2A flow reflects this rather than fighting it.
2. Keeps Components Independent
A unit responsible for classification doesn’t need to know how tariff logic works—and vice versa.
3. Makes Integration Cleaner for Developers
Downstream systems can call only the units they need.
No one is forced to adopt a monolithic API surface.
4. Supports Long-Running Processes Gracefully
Some tasks—like dependency graph construction or large-scale analysis—simply take time.
5. Increases Transparency and Auditability
Each unit has a single responsibility and a well-defined output shape.
A2A as an Integration Interface, Not an Orchestration Layer
An important distinction:
We didn’t design A2A to choreograph agents internally.
Instead, it serves as a clean integration interface for external systems:
- enterprise applications
- compliance engines
- procurement analytics
- risk monitoring tools
- internal data pipelines
Any downstream system can call the specific units it needs without adopting a new platform.
When to Use A2A Over Traditional APIs
This pattern tends to work best when:
✔ tasks are long-running
✔ workflows unfold across multiple steps
✔ reasoning or validation must be transparent
✔ deterministic, structured results are needed
✔ you want modular capabilities instead of a monolith
If a workflow is truly single-step and instantaneous, a regular synchronous API makes more sense.
Want to Explore the Spec?
The full A2A protocol, schema definitions, and integration examples are documented here:
👉 https://github.com/SupplyGraphAI/supplygraph-ai
We’re continuing to refine this pattern as we build more components around supply chain intelligence, and we’re always interested in feedback from engineers who work on similar problems.
If you’ve designed similar architectures—or have experience with long-running or multi-step supply chain workflows—I’d love to hear how you approached it.
