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, milestones, and acceptance

Boundary

An example starting scope covers one business capability, a small number of source systems, a proposed pilot interface, and an architecture review. We agree the systems, review cycle, and deliverables; production implementation, data remediation, security certification, and vendor fees are handled explicitly.

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. The proposal fixes source systems, endpoints, organizations and users, environments, and acceptance tests. 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

The proposal fixes business actions, systems, roles, approvals, limits, recovery behavior, and acceptance tests. Validation, idempotency, and audit history 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. Scope reflects source count and condition, permission groups, update frequency, document volume, and evaluation requirements. Model, OCR, vector, hosting, and other third-party usage are separate.

Experience

A role-aware conversational interface grounded in approved company knowledge, with citations that let employees inspect the source behind each supported answer.

Production system

• Conversational interface, RAG, and citations
• Permissions and unsupported-answer controls
• Feedback, evaluations, and analytics
• Pilot deployment with defined users and acceptance tests

Boundary

An internal assistant answers from approved knowledge. Live business facts, workflow preparation, approvals, and transactions require separately scoped system access and authority controls.

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. MCP is a governed interface over dependable services—not a substitute for the APIs, permissions, or systems beneath it.

Authority ladder

1. Read-only retrieval
2. Draft and prepare
3. Approval-gated action
4. Transactional authority
5. Multi-agent coordination

Forge delivery

• Versioned AgentContract for purpose, instructions, model policy, and structured input-output
• Fixed tool registry connected to approved APIs, RAG, and MCP capabilities
• Tenant isolation, least-privilege access, citations, rate limits, and usage budgets
• Deterministic builds, live behavior and security evaluations, deployment, approvals, and handoff evidence

Current boundary

The current standard Forge profile is the first category: one synchronous, fixed-tool, read-and-retrieval agent with request-scoped memory. Writes, persistent memory, dynamic tool discovery, browser or computer control, sub-agents, agent handoffs, and multi-agent orchestration require separately designed and validated capability profiles.

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. Implementation scope reflects workflow authority, connected systems, volume, and acceptance conditions. Uncertain or financially meaningful actions escalate to people.

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 named integration is scoped by transport, authentication, mappings, environments, test access, owner, and maintenance boundary. Third-party limitations and financially meaningful writes require additional safeguards; external licensing and usage are separate.