Skip to content

Extension Roadmap

Target Architecture — Final-State Design

This page describes how the Integration Platform is designed to grow. The 14 services, 5 workers, and 8 aggregates documented elsewhere are the stable core; the roadmap below shows the extension points that let the factory add new external reach without changing that core.

The platform's whole purpose is reach, and reach is never "done" — new vendors, model providers, and business systems appear continuously. The Integration Platform is therefore built as an extension surface: adding connectivity is a matter of registering a provider and a versioned API client, not rebuilding services. This is what keeps external integration reusable, governed, and traceable as the surface expands across the multi-tenant estate.

Extension Principles

  • Provider, not code. A new vendor is added by registering an IntegrationProvider and an ExternalApiClient in the Vendor Registry — the owning service stays unchanged because it depends on capability interfaces, not concrete vendors.
  • Adapters over forks. New communication, model, or cloud vendors slot in behind the existing provider-abstracted adapters (the same pattern that makes Twilio / Israel019 / ACS interchangeable today).
  • Events stay canonical. Every new integration emits the same envelope and reuses the existing event types where semantics match; new event types follow NounVerbPastTense.
  • Governed by default. A new provider inherits credential custody, rate limiting, signature verification, and audit automatically — security is a platform property, not per-integration work.
  • Reuse is first-class. A ConnectSoft.*.ApiClient proven on one tenant/project becomes a catalogued, versioned asset reusable everywhere.

Future Services

Candidate Service Bounded Context Purpose
ObjectStorageIntegrationService Cloud Provider Normalise S3 / GCS / Azure Blob-compatible object stores behind one surface
DataWarehouseIntegrationService Business Systems Push/pull against Snowflake / BigQuery / Synapse for analytics
IdentityProviderIntegrationService Business Systems SCIM / SSO integration with external IdPs
MessagingIntegrationService Communication Push, WhatsApp, and chat-channel providers beyond email/SMS
AnalyticsIntegrationService Business Systems Generalise GoogleAnalytics.MeasurementProtocol + Meta.Conversions into a unified analytics egress
ObservabilityVendorIntegrationService Business Systems Forward signals to external APM/SIEM vendors

Future Workers

Candidate Worker Trigger Purpose
ProviderCertificationWorker New/updated ExternalApiClient Run a conformance suite before a client is promoted to Active
RateLimitTuningWorker Schedule + usage telemetry Auto-tune per-provider rate-limit profiles from observed limits
WebhookReplayWorker On-demand / batch Bulk-replay dead-lettered deliveries after a vendor incident
CostAttributionWorker Schedule Attribute vendor spend (model tokens, SMS, API calls) per tenant/project
SecretExpiryForecastWorker Schedule Predict and pre-empt credential expirations across the estate

Future APIs

  • GET /integrations/providers and GET /integrations/providers/{providerId}/capabilities — discovery surface for the marketplace and agents.
  • POST /integrations/connections/{connectionId}/test — explicit connection self-test action.
  • GET /webhooks/deliveries/{deliveryId}/attempts — full attempt history for audit/replay.
  • POST /webhooks/deliveries/{deliveryId}/replay — governed replay action.
  • GET /integrations/usage — per-tenant rate/cost usage for quota dashboards.

Integration-Pack Marketplace

The largest extension axis is a marketplace of integration packs — versioned bundles that make a whole vendor turnkey:

  • An integration pack bundles an IntegrationProvider definition, one or more versioned ExternalApiClients, capability declarations, default RetryPolicy/RateLimitProfile, webhook signature schemes, and Factory Studio configuration forms.
  • Packs are published, versioned, and discovered through the Marketplace alongside templates and libraries, with the same governance and reuse tracking.
  • Installing a pack into a tenant registers its provider and clients and exposes its capabilities to agents and operators — no deployment change required.
  • Proven first-party packs (Deputy, Braze, Bill, Twilio, Israel019, ACS, GA Measurement Protocol, Meta Conversions, Azure DevOps, GitHub, OpenAI, Azure OpenAI, Ollama, MCP) seed the marketplace as Implemented assets that third parties can extend.

Agent Opportunities

The Integration Platform is uniquely positioned to become agent-operable, turning external connectivity into autonomous capability:

  • Self-service integration. An agent in the Agent Mesh, given a capability need, can discover a provider from the registry, request a connection, and (subject to governance approval) wire it into a generated SaaS — closing the loop from intent to live integration.
  • MCP tool expansion. McpConnectorService lets agents call external tool servers as governed tools; the roadmap generalises this so any registered provider capability is automatically exposed as an MCP tool.
  • Autonomous remediation. Agents consume IntegrationFailed and health signals to diagnose vendor issues, propose credential rotation, or open a provider support ticket via SupportIntegrationService.
  • Pack authoring by agents. Agents draft new integration packs from a vendor's OpenAPI/SDK spec, generating the ExternalApiClient, capability map, and Studio forms for human review — making the marketplace itself self-extending.
  • Cost-aware routing. Agents use usage and cost telemetry to choose between model providers (OpenAI vs Azure OpenAI vs Ollama) per task, balancing latency, quality, and spend.