Outcome

An implementation-ready definition of who the API serves, what it exposes, how it is secured, and how the pilot will be accepted.

Typical scope

• Source systems and authoritative data
• Users, account isolation, and authentication
• Pilot endpoints and initial OpenAPI contract
• Monitoring, risks, acceptance tests, and schedule
• Support requirements, implementation phases, and milestone pricing

Boundary

Discovery and architecture only. Production implementation is scoped separately.

Outcome

An implementation-ready architecture and phased choice between customer-first, supplier-first, or combined implementation.

Typical scope

• APIs, events, webhooks, and MCP tools
• Identity, permissions, and canonical data
• Source-system integration and pilot options
• Testing, hosting, monitoring, and support plan

Boundary

Produces an implementation-ready architecture without obligating the client to proceed with a build.

Outcome

Authorized customers, partners, applications, or assistants can retrieve current information through a documented, monitored interface.

Typical scope

• Partner authentication and account isolation
• Catalog, pricing, availability, packs, and lead times
• Existing-order and order-status lookup
• Documentation, sandbox, monitoring, and audit history

Boundary

Read access only. No ordering, autonomous transactions, or changes to authoritative systems.

Outcome

Approved users and systems can prepare and submit valid transactions while the authoritative business system remains in control.

Typical scope

• Draft carts, quotes, or orders
• Pack, minimum, ship-to, account, and credit checks
• Approval-gated submission and authoritative references
• Acknowledgments, changes, substitutions, and webhooks

Controls

Validation, idempotency, approvals, audit history, resilience, and recovery are required for financially meaningful writes.

Knowledge sources

Product documents, SOPs, policies, training, shared drives, databases, approved archives, PDFs, spreadsheets, and web content.

Production system

• Ingestion, normalization, metadata, indexing, and synchronization
• Hybrid search and permission-aware retrieval
• Source citations and unsupported-answer controls
• Freshness, deletion, evaluations, feedback, and monitoring

Boundary

RAG is for approved knowledge—not rapidly changing facts such as live inventory, account pricing, credit, orders, or shipments. Those remain in authoritative APIs and databases.

Possible systems

Product and spreadsheet preparation, purchase-order exceptions, sales and service assistance, receiving discrepancies, or internal knowledge.

Typical behavior

• Use RAG for knowledge and APIs for current facts
• Use MCP for approved tools and controlled actions
• Extract, compare, normalize, and draft
• Create a review queue and escalate uncertainty

Boundary

Source systems remain authoritative. Uncertain or financially meaningful actions escalate to people.

Outcome

Approved AI clients can search, retrieve, prepare, validate, or submit through documented tools without duplicating the rules beneath them.

Implementation

• Tools, resources, and input-output schemas
• Connections to authoritative APIs and services
• Organization, account, user, and agent permissions
• Supported-client testing, monitoring, documentation, and emergency disabling

Controls

Read-write separation, approval gates, quantity and spending limits, duplicate-action prevention, audit history, and reapproval after material changes.

Outcome

A specific partner or system can exchange approved data and transactions through a dependable, monitored connection.

Possible transports

• APIs and webhooks
• EDI, CSV, and SFTP
• Document exchange and adapters
• Authentication, mappings, validation, and testing

Boundary

Each connector is scoped independently. Third-party limitations affect delivery; writes and financial transactions require additional safeguards.