Agentic Applications + Third-Party Integration — How They Compose

1 · Overview

The previous v3.1 docs ship the platform substrate. This document answers the harder question: can agents do real work on this substrate, and can they reach the customer's existing systems? The answer to both is yes — with one strategic addition (MCP bridge) and one framework + roster (connectors).

2 · The Agentic Substrate (what already exists)

ProjexCloud v3.1 is AI-native by design. Every primitive an agentic application needs is in the SDK estate — and is gated, audited, and metered like the rest of the platform.

2.1 · The eleven agentic primitives

2.2 · The twelve platform agents already designed

Architecture §18 defines 12 horizontal agents that ship as part of the platform — they exemplify the agentic patterns and become the first consumers of every primitive above.

• Engagement Agent — personalized nudges per persona
• CRM Intelligence Agent — lead scoring, next-best-action
• Campaign Optimizer Agent — send-time tuning, segment refinement
• Support Resolution Agent — summarization, suggested replies, auto-escalation
• Content Intelligence Agent — auto-tagging, summaries, embeddings
• Commerce Recommender Agent
• Event Engagement Agent
• Operations Monitor Agent — SLA breach + anomaly detection
• Executive Intelligence Agent — KPI digests, cohort trends
• Knowledge Curator Agent — quality scoring, dedup, refresh
• Onboarding Agent — new tenant configuration walk-through
• Cost & Safety Steward Agent — usage-driven recommendations, kill-switch suggestions

2.3 · How a tenant developer's agentic app composes

// A custom app's agent loop (using only platform SDKs)

import { resolveIdentityContext } from '@projexlight/sdk-identity-resolver/client';
import { AgentRuntime } from '@projexlight/sdk-agent-runtime/client';
import { Intent } from '@projexlight/sdk-semantic/client';
import { conversation } from '@projexlight/sdk-conversation/client';

const ctx = await resolveIdentityContext(token);
const agent = AgentRuntime.create({
  agent_id: 'patient-care-coordinator',
  acting_for: ctx.primary_persona_id,
  scope: ['crm.read', 'engagement.encounter.create', 'notification.send'],
  ttl_seconds: 300,
});

// Express the goal as a SemanticIntent — not a prompt
const intent: Intent = {
  goal: 'schedule_follow_up_visit',
  subject: { type: 'Patient', id: 'pers_ravi_hA_patient' },
  parameters: { within_days: 14, prefer_morning: true },
};

// Agent walks the CapabilityGraph to produce a plan
const plan = await agent.plan(intent);   // returns a typed multi-step plan
const result = await agent.execute(plan); // each step gates through @meter + capability tokens

// Everything audited, traced, billed, and replay-able
console.log(result.trace_id);            // open in sdk-trace UI

3 · The Three Integration Categories

Every third-party system fits exactly one of three categories. Knowing which one prevents wasted effort.

3.1 · Category A — We REPLACE (we have our own primitive)

Tools where ProjexCloud is the answer. Customer migrates off these.

3.2 · Category B — We INTEGRATE (third-party is a pluggable backend)

Provider-style backends behind our typed SDK abstractions. Tenants pick the provider; SDK handles the interface. No lock-in.

3.3 · Category C — We CONNECT (reach into customer's existing tools)

The real gap. Enterprises already use Salesforce, Snowflake, Slack, M365, Jira — ProjexCloud agents need to read/write these to do useful work. Two new primitives close the gap: sdk-mcp-bridge (§4) and sdk-connectors framework + per-target packages (§5–6).

4 · sdk-mcp-bridge — The Strategic Primitive

Model Context Protocol (MCP) is an open standard for letting LLMs invoke tools across systems. Public MCP servers already exist for Slack, GitHub, Snowflake, Postgres, file systems, and dozens more — and the list grows monthly. By implementing MCP both ways, ProjexCloud agents become interoperable with any MCP-compatible system, present or future.

4.1 · How MCP fits the existing gate model

sequenceDiagram
  participant A as Agent
(sdk-agent-runtime)
  participant CG as CapabilityGraph
(sdk-semantic)
  participant MCP as sdk-mcp-bridge
  participant META as sdk-meter
  participant EXT as External MCP server
(Slack / Snowflake / GitHub)
  participant AUD as sdk-audit
  participant TRC as sdk-trace

  A->>CG: plan(intent)
  CG-->>A: plan: [internal-tool-1, MCP-tool-2, internal-tool-3]
  loop For each step
    A->>META: gate.check(sku, token)
    META-->>A: ALLOW (capability token minted)
    alt Internal tool
      A->>A: invoke directly
    else MCP tool
      A->>MCP: invoke(mcp-server, tool, args, token)
      MCP->>MCP: fetch credentials from sdk-vault
      MCP->>EXT: MCP request (stdio/SSE/HTTP)
      EXT-->>MCP: tool response
      MCP-->>A: typed result
    end
    A->>AUD: record step (with mcp_server_id if MCP)
    A->>TRC: trace span
  end
    

4.2 · What customers can do once this ships

• Plug their own internal MCP servers (custom proprietary systems) into ProjexCloud agents — no per-system connector required.
• Use any public MCP server (Slack, GitHub, Postgres, Snowflake, Notion, Linear, …) without us building it.
• Expose ProjexCloud as a tool source to their other AI systems (Claude Desktop · custom OpenAI assistants · agentic apps in other platforms).
• Replay any agent decision deterministically including MCP tool calls (the bridge captures request/response in the execution log).

5 · sdk-connectors — The Framework

For high-value targets where MCP isn't yet sufficient (deep schema-aware sync, large-volume bulk APIs, vendor-specific authz models, bidirectional state reconciliation), we ship typed connector packages. They all share one framework.

6 · Per-Target Connector Roster

The phased roster. Each connector follows the same template, phased by enterprise impact.

7 · How Agents Use Connectors

Connectors integrate with agents through the CapabilityGraph in sdk-semantic. Every connector's operations register as tools the agent can plan against.

7.1 · The end-to-end flow

flowchart TB
  classDef intent fill:#241f10,stroke:#f5c451,color:#fff;
  classDef sem fill:#16241c,stroke:#2dd4bf,color:#fff;
  classDef agt fill:#1d1830,stroke:#b88dff,color:#fff;
  classDef tool fill:#0f1422,stroke:#6aa9ff,color:#fff;
  classDef ext fill:#162420,stroke:#5dd39e,color:#e6ecf5;

  USER["Tenant employee enters intent in
Tenant Workspace conversation"]:::intent
  INTENT["SemanticIntent
'Schedule a follow-up with this
patient · log it in Salesforce ·
notify the care team in Slack'"]:::sem
  CG["CapabilityGraph
(sdk-semantic)
Lists ALL tools available:
internal SDKs + MCP tools + connectors"]:::sem
  PLAN["Agent planner produces plan:
1. engagement.encounter.create
2. connector-salesforce.activity.log
3. connector-slack.post-message"]:::agt
  STEP1["Step 1: internal sdk-engagement"]:::tool
  STEP2["Step 2: connector-salesforce"]:::tool
  STEP3["Step 3: connector-slack"]:::tool
  SF["Customer's Salesforce instance"]:::ext
  SL["Customer's Slack workspace"]:::ext

  USER --> INTENT
  INTENT --> CG
  CG --> PLAN
  PLAN --> STEP1
  PLAN --> STEP2
  PLAN --> STEP3
  STEP2 -.->|OAuth · vaulted| SF
  STEP3 -.->|OAuth · vaulted| SL
    

7.2 · Why this is safe

• Capability tokens enforce scope — agent can only call connector tools its scope permits, mid-execution revocation works.
• Connector credentials are vaulted per tenant; never in agent prompts; sdk-vault tier hierarchy applies.
• External tool responses pass through the same audit + lineage trail — "this Salesforce field updated because Agent X executed Plan Y at time Z" is one query in sdk-trace.
• Deterministic replay includes connector calls — the execution log captures request + response; replay reproduces exactly (allowing for external state changes between then and now, surfaced as a diff).
• Cross-tenant leakage impossible — connector instances are per-tenant; tokens are per-tenant; even if Tenant A's agent and Tenant B's agent both use connector-salesforce, they use different OAuth tokens against different Salesforce orgs.

8 · Tenant Developer Experience

8.1 · Building an agentic custom app that uses external systems

// In tenant's custom app — wire up an agent that crosses systems

import { resolveIdentityContext } from '@projexlight/sdk-identity-resolver/client';
import { AgentRuntime } from '@projexlight/sdk-agent-runtime/client';
import { conversation } from '@projexlight/sdk-conversation/client';

const ctx = await resolveIdentityContext(token);

// Tenant admin has already:
//   - Connected Salesforce in Tenant Admin → Connectors
//   - Connected Slack in Tenant Admin → Connectors
//   - Optionally registered a custom MCP server for their proprietary tool
// Those tools auto-appear in this agent's CapabilityGraph

const agent = AgentRuntime.create({
  agent_id: 'cross-system-orchestrator',
  acting_for: ctx.primary_persona_id,
  scope: [
    'engagement.encounter.create',
    'connector.salesforce.activity.log',
    'connector.slack.post-message',
    'mcp.custom-proprietary-tool.read',
  ],
  ttl_seconds: 120,
});

const intent = {
  goal: 'follow_up_workflow',
  subject: { type: 'Customer', id: ctx.subject_id },
  parameters: { meeting_type: 'discovery', urgency: 'high' },
};

const plan = await agent.plan(intent);
// plan = [
//   { tool: 'engagement.encounter.create', args: {...} },
//   { tool: 'connector.salesforce.activity.log', args: {...} },
//   { tool: 'connector.slack.post-message', args: { channel: '#sales-followups', ... } },
//   { tool: 'mcp.custom-proprietary-tool.read', args: {...} },
// ]

const result = await agent.execute(plan);
// Each step audited; bill shows the per-tool cost split (internal vs. connector vs. MCP)
// Open result.trace_id in sdk-trace UI to see the full timeline

8.2 · Registering a custom MCP server

// Tenant admin in Tenant Admin Portal → AI → MCP Registry

POST /v1/mcp-bridge/servers
  {
    name: 'internal-pricing-tool',
    transport: 'http',
    endpoint: 'https://pricing-tool.internal.tenantco.com/mcp',
    credentials_ref: 'secret://tenant/12345/mcp-pricing-token',
    allowed_agents: ['cross-system-orchestrator', 'pricing-agent'],
    allowed_tools: ['price.lookup', 'price.calculate'],  // null = all advertised
  }

// Tools immediately appear in the CapabilityGraph for those agents
// Every invocation is gated, metered, audited, traced — same as any other tool

9 · Phase Mapping (where these land)

9.1 · SDK count impact

• v3.1 platform was at 55 SDKs after the prior phase plan work.
• This document adds: sdk-connectors + sdk-mcp-bridge + 8 to 10 connector-* packages in the platform monorepo (P4–P6B).
• Industry-vertical connectors (Epic, Cerner, MLS, Bloomberg) live in the corresponding vertical repos — they're not platform SDKs.
• New platform SDK count: ~67 (55 + 2 framework + ~10 high-priority connectors).

Appendix · Cross-references