note №.008 · 2026 · 05 · 209 min - or one SSO callback too many

Designing enterprise AI integrations
for operational systems.

Messaging, identity, ticketing, search, security tools, and internal APIs are the architecture around the model.

Enterprise AI becomes useful when it enters existing work without losing identity, context, reliability, or control.

A standalone AI interface can answer questions. Operational systems must also know who is asking, which records they may access, what workflow is in progress, and whether a proposed action is allowed.

Integration architecture is what turns a model feature into part of the enterprise.

Start with the unit of work.

Do not begin with a list of connectors.

Begin with a workflow such as:

  • investigate an alert;
  • prepare a customer-risk review;
  • summarize a production incident;
  • resolve an access request;
  • draft a change with evidence.

Map its actors, systems of record, events, decisions, actions, approvals, and completion criteria. Integrate only what the workflow needs.

Preserve identity end to end.

The user authenticated in Slack, a web app, or a ticketing system must not become an anonymous model request with a shared service credential.

Carry:

  • principal;
  • tenant;
  • role;
  • delegated authority;
  • case or request scope;
  • data entitlements;
  • approval state.

Use short-lived credentials and server-side policy checks. The model should not choose the tenant or expand its own scope.

Separate events, queries, and commands.

These integration shapes have different contracts.

Events announce that something happened. They need stable IDs, deduplication, ordering assumptions, versioned schemas, and replay handling.

Queries retrieve current or historical information. They need authorization, pagination, freshness, source metadata, and bounded results.

Commands change state. They need validation, idempotency, policy, approval, audit, and a clear result.

Hiding all three behind one generic tool makes recovery and governance harder.

Build adapters around canonical contracts.

Vendor payloads change. Internal workflows should not.

Translate external records into stable domain objects such as:

  • evidence;
  • entity;
  • alert;
  • case;
  • finding;
  • action proposal;
  • approval;
  • execution result.

Preserve the raw source and provenance. Avoid a universal schema that erases details; use a stable common envelope plus source-specific attributes.

Design for asynchronous work.

Enterprise actions often take longer than one request. They wait for rate limits, approvals, background jobs, or human responses.

Use durable workflow state with correlation IDs, deadlines, cancellation, bounded retries, and compensating actions. Publish state transitions so the user can see progress.

A chat transcript is not a workflow database.

Treat retrieved content as untrusted.

Tickets, documents, messages, and web pages can contain malicious instructions. OWASP describes indirect prompt injection as attacker-controlled content that later enters a model's context.

Mark sources, delimit retrieved data, validate model outputs, and enforce tool permissions outside the prompt. Retrieved text can supply evidence; it cannot grant authority.

Make failures explicit.

Normalize integration failures:

  • authentication expired;
  • permission denied;
  • object missing;
  • rate limited;
  • upstream unavailable;
  • conflict;
  • partial result;
  • validation failed;
  • approval required.

The workflow should know which errors are retryable and which require a person. Blind retries can duplicate tickets, actions, and cost.

Observe the full operation.

Trace the journey from user request through retrieval, model calls, tools, policy, approval, and final system-of-record update.

Record versions and identifiers without copying sensitive payloads into every telemetry system. Measure completion, latency, correction, reliability, and cost for the whole unit of work.

Operate connectors as products.

Each integration needs:

  • an owner;
  • supported API versions;
  • permission documentation;
  • health and rate-limit monitoring;
  • contract tests;
  • sandbox fixtures;
  • deprecation policy;
  • customer-visible failure behavior.

Connector count is a weak platform metric. Reliable workflow coverage is much stronger.

The design review questions.

Before releasing an integration, ask:

  1. Which identity and tenant reach every operation?
  2. What is the system of record?
  3. How are duplicates and retries handled?
  4. Can untrusted content influence a command?
  5. What does partial failure look like?
  6. Which actions require approval?
  7. Can the workflow be resumed and audited?
  8. How will API changes be detected?
  9. What data enters prompts, logs, and traces?
  10. How can the integration be disabled safely?

Enterprise integration is not glamorous. It is where an AI product proves that it can participate in real operations rather than sit beside them.

Sources and further reading.

filed under →aiinfrastructureenterpriseworkflow
↬ read next:

The interesting boundary around the model.

Most "AI product" work is really tool design, approval-flow design, and observability. The model just sits in the middle, doing the easy part. A short essay on what actually makes these systems good.

continue →