Skip to content

How we built an AI IT assistant for an enterprise service desk

Summary

A Redpanda customer case-study (2026-10-27, Tier 3) describing an AI IT-service-desk assistant built on the Redpanda Agentic Data Plane (ADP) for an unnamed enterprise. The assistant lives in Microsoft Teams, classifies each employee message as a question, an incident, or a service-catalog order, first tries to answer from knowledge-base articles the employee is allowed to read, and otherwise reads the live form definition from the existing ITSM platform, validates the model's proposed field values against it, submits through the platform's normal intake/ordering interfaces, and then reads the saved record back to confirm what actually persisted. Every model call and tool call traverses ADP's AI Gateway; tools are exposed through a custom, task-scoped MCP server (find article / read form / create incident — no generic table-query tool). Writes run under the employee's own OAuth identity pulled from a token vault; a separate read-only service account does form-definition and verification reads. Admin controls layered on top: Cedar tool-access policies (deny-by-default, forbid wins, forbid-eval-failure denies), request/response data policies (preview), Bedrock Guardrails on prompts/outputs, OpenTelemetry traces + OCSF audit events published to Redpanda topics, and per-agent spend budgets. Headline number: 36% of employee requests in week one were resolved by the assistant alone from existing KB articles, never becoming tickets. The ITSM platform remains the system of record for records, permissions, and approvals.

Key takeaways

  1. The agent prepares; the system of record decides. The ITSM platform keeps forms, accepted values, routing rules, permissions, and approvals. The pipeline is split into four layers with distinct jobs: model picks a task and proposes arguments → gateway authorizes the call → MCP server turns the task into a validated application request → ITSM applies its own permissions/workflow/approvals. Chat confirmation does not replace a required manager approval. (Source: this page)
  2. Task-scoped MCP server instead of a generic data connector. The MCP server exposes only named IT tasks; it has no general query tool over platform tables, which bounds what the model can attempt even when it misreads a request — a direct instance of patterns/tool-surface-minimization. Unwanted operations (e.g. closing incidents, which stays human) can simply be left out of the tool surface rather than policed. (Source: this page)
  3. Schema-driven validation from the live form, per request. The integration fetches required fields, accepted values, defaults, dependencies, and inherited shared field groups each time a request arrives and validates the model's answers in code (patterns/deterministic-tool-vs-llm-judgment). Because the form is read at runtime, IT changes a supported form rule and the assistant follows it without a release. Routing (assignment group, location, callback details) is applied deterministically at creation time. (Source: this page)
  4. Read-after-write verification, because a 2xx isn't proof. An employee may be allowed to create a request without being able to read every field on it, so a successful API response doesn't prove the record is complete. The assistant re-reads the saved record via a read-only client and diffs it against what was submitted; if a follow-up update fails it keeps the record number and flags unverifiable values. (Source: this page)
  5. On-behalf-of writes via a token vault; separate read identity. Writes use the employee's own OAuth connection, selected by ADP from its token vault (encrypted, tenant- and user-isolated, handles refresh), so credentials never appear in prompts or tool arguments and the assistant can do only what the employee could (patterns/on-behalf-of-agent-authorization). Form-definition and verification reads use a distinct read-only account whose permissions need their own review, since those reads can still expose enterprise data. (Source: this page)
  6. Cedar tool policies: deny-by-default, forbid overrides permit, fail-closed on forbid errors. Policies match principal / action / resource with group-membership and resource-attribute conditions (e.g. everyone can search KB; only some can create/modify records; a support group can invoke tools without editing their configuration). In ADP a forbid that fails to evaluate denies. Policy updates propagate asynchronously — verify enforcement after a change. (Source: this page)
  7. Data policies constrain arguments and responses (preview). Request rules constrain argument values or strip fields (e.g. refuse a demand for the top incident priority); response rules mask/drop fields and filter records before results reach the model. Multiple matching policies combine restrictively, and a call is denied if a matching rule can't be enforced. Constraints can also be surfaced in the tool schema the model sees, then re-checked at the gateway — but rules must match the real schema including alternate argument paths. (Source: this page)
  8. Guardrails are one layer, not the defense. ADP guardrails scan prompts/responses for sensitive data, disallowed topics, and prompt attacks, with detect / block / redact actions. The documented backend is Amazon Bedrock Guardrails even when another provider hosts the model — text is shipped to Bedrock, so its destination/region belongs in the data-handling review. A failed required guardrail check rejects the request. The post says guardrails "won't catch every malicious instruction", hence tool permissions, argument constraints, and ITSM checks still matter (concepts/defense-in-depth). (Source: this page)
  9. Audit trail on the log. OpenTelemetry ties agent activity, model calls, and tool calls together; with audit enabled, security events are emitted in OCSF (actor, operation, resource, outcome); the gateway's MCP audit path records authorization decisions including refusals and publishes to Redpanda topics for retention/analysis (patterns/durable-event-log-as-agent-audit-envelope). Operators reconstruct "where did my ticket go" by joining conversation → gateway decision → tool result → saved ITSM record. Traces can contain sensitive argument data, so access to them must be limited. (Source: this page)
  10. Budgets fail open — explicitly. Per-agent model-spend limits reject the next model call once recorded spend reaches the limit, but if current spend can't be read the request goes through. Redpanda says to treat it as "a strong safeguard rather than a hard ceiling" — a candid asymmetry against the fail-closed authorization path (concepts/fail-open-vs-fail-closed). (Source: this page)

Architecture (logical request path)

Employee (Microsoft Teams)
   │
   ▼
IT assistant agent ──► ADP AI Gateway ──► LLM provider
   │                     │  Cedar tool policy (deny-by-default)
   │                     │  data policies (args in / fields out)
   │                     │  guardrails (→ Bedrock Guardrails)
   │                     │  budgets, OTel traces, OCSF audit → Redpanda topics
   │                     ▼
   │               Task-scoped MCP server
   │                 find_article / read_form / create_incident / order_item
   │                 (no generic table query)
   │                     │ employee OAuth (token vault)   read-only svc account
   │                     ▼                                 ▼
   └────────────── ITSM platform (system of record: forms, routing,
                    permissions, approvals) ◄── read-back verification

Request flow for "my laptop is broken": (1) KB search scoped to the employee's access → stop if solved; (2) read incident form definition, validate proposed answers, ask for missing fields; (3) submit via intake form with location/callback/routing applied; (4) read the saved record back and report what was confirmed. Catalog orders with required acknowledgments (e.g. a training notice for a software license) collect an explicit employee answer in chat before submission.

Operational numbers

  • 36% of employee requests in the first week answered by the assistant from existing KB articles alone — no ticket, no human.
  • No latency, volume, model, or cost figures disclosed.

Systems / concepts / patterns extracted

Caveats

  • Vendor case study on a Tier-3 blog; the customer and ITSM product are unnamed and the only metric is the 36% deflection figure (one week, no baseline or denominator disclosed).
  • The post explicitly states that the controls section describes what ADP supports, not necessarily what was enabled for this customer; data policies are in preview. Treat the control list as product capability, not deployment evidence.
  • Budget enforcement is fail-open on spend-read failure; Cedar policy updates propagate asynchronously — both are windows where configured controls may not hold.
  • Guardrail evaluation routes text to Amazon Bedrock regardless of the model provider — a data-residency consideration.

Source

Last updated · 854 distilled / 2,448 read