Client Context
A UK-based FinTech scale-up was running a lean platform team responsible for cloud operations, incident response, and change delivery (Kubernetes, IaC, CI/CD, observability). As the company expanded into new markets, operational load didn’t grow linearly, but it spiked!
The biggest pain wasn’t tooling. It was coordination: every “simple” request became a multi-team puzzle across logs, runbooks, security approvals, Jira, and Git.
Challenge
Most operational goals were “one sentence requests” hiding 10–25 sub-tasks, for example:
- “Investigate elevated 5xx errors on Checkout API.”
- “Provision a new tenant environment with least-privilege access.”
- “Prepare a change plan + rollout comms for the next release.”
Human engineers were spending too much time on:
- Manual triage (finding the right signals, dashboards, owners)
- Context rehydration (why this system is wired this way)
- Handoffs that caused delays and broken accountability
They wanted an agentic system that could decompose goals into structured work, distribute tasks across specialist agents, and keep humans in control of high-impact actions (a pattern strongly aligned with modern multi-agent reference architectures and governed orchestration).
Collaborative Approach
We ran a short discovery + pilot with four groups:
- Platform Engineering: Runbooks, tooling, on-call process
- Security & Compliance: Approval gates, audit expectations
- SRE/Operations: Incident playbooks, escalation rules
- Product/Support: Business impact context, customer comms
Instead of “build an AI agent,” we treated it like designing a digital workforce:
- Define roles
- Define decision boundaries
- Define the work routing logic
- Define what must go through human approval
Solution
We implemented an Agentic AI Workflow Decomposition layer that sits between incoming work (Slack/Jira/PagerDuty) and execution (tools, docs, engineers).
The system’s core idea:
One goal → Decomposed into a task graph → Routed to specialist agents → Validated → Executed with guardrails.
The orchestration followed a Plan-then-Execute style: separate strategic planning (decomposition, routing, constraints) from tactical execution (tool calls, drafts, patches). This improves predictability vs purely reactive loops.
Core Components
Borrowing from modern multi-agent patterns, the platform included:
Orchestrator
- Owns the run lifecycle, state, retries, timeouts
- Handles handoffs + concurrency (parallel sub-tasks)
Planner / Decomposer Agent
- Converts goal → Work Breakdown Structure (WBS)
- Outputs a task graph with dependencies, success criteria, and risk level
- Assigns tasks to specialist agents based on capability + tool access
Specialist Agents (role-based)
- Context Agent: Retrieves runbooks, recent incidents, service ownership
- Diagnostics Agent: Log queries, metrics checks, hypothesis generation
- Remediation Agent: Proposes safe actions, creates change steps
- Comms Agent: Drafts stakeholder updates + customer-safe summaries
- Risk/Policy Agent: Checks tool allowlists, data scopes, approval rules (policy-as-code style)
Memory + Evidence Store
- Short-term run state + artefacts (queries, links, findings)
- Long-term knowledge pointers (runbooks, postmortems, decision logs)
Human Approval Gates
- Anything “write-impacting” (deploy, config change, external comms) required explicit approval
- Approvals were attached to a complete evidence trail (what/why/impact)
Technical Implementation
Architecture choices
- Graph-based workflow orchestration for branching, retries, parallel workstreams, and clear state transitions, which can be a strong fit for multi-agent collaboration.
- Agent registry + routing so new agents/tools could be added without rewriting the whole system (extensible, workflow-centric design).
Decomposition mechanics (how goals became task graphs)
The Planner used a consistent template:
- Goal statement (what “done” means)
- Constraints (time, environment, risk, policy)
- Subtasks grouped into phases: 1) Context build → 2) Diagnosis → 3) Option generation → 4) Validation → 5) Execution → 6) Comms + closure
- Dependency rules (what must happen before what)
- Confidence + escalation criteria (when to stop and ask humans)
Example (simplified): “Checkout API 5xx spike”
- Context Agent:
- Pull dashboards, recent deploys, incident history
- Diagnostics Agent (parallel):
- Fetches logs and error
- Remediation Agent:
- Propose rollback vs config tweak vs traffic shaping
- Generate step-by-step change plan
- Risk/Policy Agent:
- Enforce “no production writes without approval”
- Check whether actions touch regulated data
- Comms Agent:
- Internal update (eng + support)
- Customer-safe status wording
Observability & audit
- Every run produced a trace: Goal → Plan → Actions → Outputs → Approvals
- This matched the organisation’s need for reviewable histories and post-incident learning loops, and supports GenAI governance expectations.
Measurable Outcomes
Over a 6-week pilot (on two workflows: incident triage + standard change requests):
- ↓ 38% average time-to-triage (faster “what’s going on?” answers)
- ↓ 27% mean time to resolution on repeatable incident classes
- ↑ 22% change success rate (fewer rollbacks due to missing steps)
- ↓ ~30–40 minutes saved per incident in manual context gathering
- Higher consistency in stakeholder updates (same structure, fewer missing details)
(These were internal pilot measurements from run logs, Jira cycle times, and on-call retros.)
