04 — Anonymised delivery
A mainland enterprise · data-platform engineering
Data-platform Agent runtime and MCP tool plane
Turn platform on-call knowledge into a repeatable operating loop.
The data platform covered scheduling, heterogeneous sync, lakehouse ingestion and BI, but its OpenAPI surfaces were spread across subsystems. On-call engineers spent time stitching together task instances, logs, SQL and lineage by hand; recurring inspection and tuning were difficult to standardise.
We built a shared Agent runtime with hexagonal boundaries and an MCP tool plane. A scheduled or chat-triggered run can inspect an instance, fetch log artifacts, analyse SQL and lineage, propose a rerun or tuning change, and keep identity, policy and trace context across the loop.
In the work
One runtime, many tools
Scheduling, sync, alerts, logs, metadata and SQL APIs are adapters behind one operating contract.
Guarded operations
Scoped tool policy, OAuth identity, conversation isolation and approval gates keep write actions bounded.
Evidence in the loop
Trace IDs connect the reasoning, tool calls and artifacts so an answer can be replayed and reviewed.
The problem
A large data platform had recurring on-call work across scheduling, sync, BI and lakehouse systems. Engineers spent 30+ minutes locating failures, weekly inspection scripts took 2–4 hours, and the scattered control-plane APIs made self-service hard to scale.
Measured result
Hourly full-scope inspection replaced 2–4 hours of weekly manual scripts. Typical fault localisation fell from 30+ minutes to under 5 minutes, platform on-call volume dropped 60%+, and 30%+ of task-failure questions closed through self-service for a daily user group of about 60 engineers. Typical SLA-chain recovery shortened by about one hour.
Scope
- Unified Agent runtime using hexagonal architecture and MCP adapters
- Hourly inspection, alert-driven diagnosis, user self-service and Spark SQL tuning
- Identity, scoped tool policy, guardrails, approval and end-to-end tracing
What shipped
- → MCP tool plane for jobs, instances, logs, alerts, metadata, lineage and SQL
- → Enterprise WeChat and CLI entry points sharing one runtime and trace context
- → Resource-profile and SQL-based tuning recommendations with guarded persistence
Anonymisation
The client, internal service names and operational identifiers are anonymised. Usage, time-saving and on-call metrics come from that engagement’s operating records.
Work
HSK 3 learning agent, from zero
Anonymised deliveryAgent for P0 scheduling and data sync
Anonymised deliveryDataClaw BI analysis agent
Anonymised deliveryGoverned knowledge gate for analysis Agents
Anonymised deliveryAlert-to-remediation operations Agent
Anonymised deliveryAgent control plane with guarded actions