Psiog Theme Song

Agentic ticket resolution for a business-critical five-platform data estate

Agentic ticket resolution for a business-critical five-platform data estate

Infographic showing AI ticket resolution workflow: ingestion, AI classifier, auto-resolution, validation rules, human review, resolution & closure, with exceptions and feedback loop.

Agentic ticket resolution for a business-critical five-platform data estate

Solving a growing production-support burden into an agentic pipeline – AI at the edges, rules at the core, humans for exceptions. 

Customer Details

Client:
EPC major, Houston TX
Scale:
$23B+, 50,000+ employees
Estate:
5 platforms, 100+ operating companies

Summary

One of North America’s largest specialty Engineering Services provider grows by acquisition. Each acquired operating company is integrated into a central Enterprise Data Management (EDM) layer that feeds payroll and employee information to HR and Finance. 

The estate runs on Oracle, Boomi, Talend, OneStream, and Incorta. Data from 200+ operating companies flows through a 7-layer HUB holding employee data, then out via Integration APIs to the HR/Finance portals and reporting. A lean team that delivers these integrations also supports them in production: monitoring, incidents, access provisioning, and cross- platform data lookups. 

As more companies were acquired, manual effort needed to support was not scaling with the architecture. Job alerts arrived as individual emails, root-cause analysis meant about multiple hours of hand-written queries per ticket, and daily monitoring consumed valuable engineer-hours. Rather than propose a platform, Psiog triaged the support workflow through a structured process – effort, volume, business priority, approvals, and fallback per workflow – sequencing candidates by operational impact and designing around existing SLAs. 

An agentic layer for triage was implemented covering, root-cause analysis, and monitoring, acting through verified runbooks with human gates on approvals – plus rule-based automations where manual effort was concentrated. 

Engagement snapshot

  • The customer is an EPC major headquartered in Houston, Texas, with revenues above $23B and more than 50,000 employees across utility, energy, and communications infrastructure. 
  • The M&A work stream integrates newly acquired operating companies into the data platform
  • The Data Management support stream monitors and supports production incidents – around 40 tickets a month on the integration workstream, and about 100 a week across the wider five platform estate of Incorta, the database layer, Talend, Boomi, and OneStream. 

Landscape

The customer’s data platform is an Enterprise Data Management estate built on five products. Boomi handles Enterprise Application Integration, Talend handles Data Engineering, Oracle is the database core, Incorta serves reporting, and OneStream covers financial consolidation. The estate carries employee and payroll data from 100+ operating companies, each arriving with its own source systems and data shapes, into a central HUB that holds employee data and feeds HR, Finance, and the workforce portal. 

Change data capture keeps the hub current without full reloads. Smaller company loads are refreshed in place, while larger ones are reconciled through hash comparison so that only genuine inserts and updates move forward. From the hub, the workforce portal and enterprise reporting are synchronized through controlled outbound services, and every load is governed by control tables and run statistics. 

When the customer acquires a new operating company, it enters this flow as one more horizontal trace on the same repeatable pipeline. From day one of go-live, support and maintenance takes over: the team monitors the loads, resolves production failures through a Dev to QA to Prod lifecycle closed in the ITSM platform, provisions access, and answers data lookups.

Problem definition

Every acquisition adds a company schema to this pipeline. The architecture scaled, but the manual effort to monitor and support it did not. 

  • Job alerts arrived as individual emails – one per failure and one per long-running job every hour. A production failure could sit for one to two hours before an incident was raised. 
  • Root-cause analysis meant hand-written queries across platform tables and took around two hours per ticket. 
  • Daily monitoring across the platforms consumed seven engineer-hours. 
  • Access requests came in at 10 to 15 a week, fulfilled manually across eight data-stewardship campaigns – four to five hours every week.
  • Data lookups required hand-written Oracle SQL across four schemas. Type mismatches forced two or three rewrites per query, at 15 to 30 minutes each. 
  • Mapping-table updates meant manually converting business spreadsheets into SQL – another three to five hours a week.

Solution approach & design

The problem appeared to be capacity at the surface. A lean team was onboarding acquisitions while keeping companies’ payroll data flowing, and it was losing ground on both. The first days went into mapping where that capacity actually leaked – alert emails read one by one, access requests fulfilled by hand, SQL rewritten two and three times per lookup. Once the critical break points were identified, the pain points were sized and sequenced by operational impact. Only then was each addressed, with the lightest intervention that solved it: a rule, a model, or neither. 

Each workflow went through a structured intake before build – manual steps, effort per request, volume, error rate, systems touched, approvals required, and the fallback if the automation fails. The deciding question was whether triage was rule-based or whether intelligence was required. Of the workflows classified, the majority were rule-based; AI was reserved for the two places it was genuinely needed: 

  • Cross-platform reasoning – an agentic layer on Boomi AI. A triage agent classifies and routes each ticket on arrival, platform-specific resolver agents handle standard issues through verified runbooks, an RCA step correlates across the estate and returns a plain-language summary, and monitoring agents watch the platforms continuously. 
  • Unstructured input – data-lookup tickets arrive as free-form text. A local language model extracts the entity type and search fields as structured JSON, and a rules-driven registry generates the SQL. The model reads, the rules write. 

The intake surfaced five pain points where an intervention – rule-based or AI – would return the most capacity: 

  • Job monitoring & incident creation (Talend) – alerts consolidated per environment; production failures now raise ITSM incidents automatically. 
  • Stewardship access provisioning (Talend) – access added or removed across eight campaigns through APIs, driven by approved tickets. 
  • Mapping-table SQL generation (Oracle) – business mapping files converted into validated INSERT statements, with metadata checks and skipped-row logging. 
  • Data-lookup query builder (Oracle, hybrid AI) – a local LLM parses ticket text into structured fields; a schema registry generates type-safe SQL across schemas. 
  • Runtime downtime alerting (Boomi, POC) – Atom downtime detected automatically, with a generated list of impacted scheduled processes ready for rerun. 

The design rule ran through all five builds – AI at the edges, rules at the core, humans for exceptions. Agents act only through verified runbooks. Change approvals and low-confidence resolutions stop at a human gate. Every action is logged, and every automation carries a documented manual fallback.

AI techniques & tools

  • Agentic workflow layer – built on Boomi AI and companion agents. Triage agents classify and route tickets to platform-specific resolvers working through verified runbooks, with human-in-the-loop gates on change approvals and low-confidence resolutions. 
  • Automated RCA – query generation and correlation across the five platforms, returning a plain-language summary in under five minutes against about two hours of manual investigation. 
  • Local LLM extraction – Llama 3.2 served through Ollama on the analyst machine, converting free-form ticket text into structured JSON. No external API calls; no data leaves the machine. 
  • Deterministic SQL generation – a schema registry with canonical type maps, column-alignment rules, and NULL substitution produces the SQL. No model writes code, so output is correct by construction. 
  • Rule-based automation – alert parsing and consolidation, incident creation through the ITSM REST API, and access provisioning through Talend Data Stewardship APIs. 
  • Structured intake – each workflow assessed on effort, volume, error rate, approvals, fallback, and the rule-versus-AI decision. The assessments double as the program governance record. 

AI techniques & tools

Measure
Before
After
Root-cause analysis per ticket
~2 hours, manual queries
Under 5 minutes, automated
Daily platform monitoring
7 engineer-hours/day, manual
Continuous, autonomous, proactive alerts
Support ticket flow
Manual triage and routing
~100 tickets/week through the automated pipeline
Platform operations
5 platforms worked separately
Single agentic layer with structured HITL gates
First-wave workflow automations
14-19 engineer-hours/week of manual effort
Largest items automated or in rollout; remainder in build/POC
Failure detection (integration jobs)
1-2 hours
Minutes, with auto-created incidents

What this means for the business

  • Support scales with acquisitions, not headcount. Every new operating company adds tickets and monitoring load; that growth is now absorbed by the pipeline rather than by hiring. 
  • Payroll-relevant pipelines fail loudly, not quietly. Jobs feeding HR and Finance are detected in minutes rather than hours, protecting a process that 50,000+ employees depend on. 
  • Error-prone manual work now produces validated output. Generated SQL replaces hand-written queries and their rewrite cycles, and every access change and incident is logged end to end. 
  • Integration capacity is protected. The lean M&A team stays on the work that drives the growth strategy – bringing the next operating company into the fold. 

Way forward

The next wave extends what the first wave proved, and each candidate passes through the same intake before build. 

  • The incident-creation and access de-provisioning patterns proven on Talend extend to the Boomi stream. 
  • The RCA capability grows into a dedicated Boomi support agent, bringing automated root-cause analysis to the integration workstream the M&A team supports today. 
  • Deployment comparison across environments turns a manual pre-release check into an automated quality gate. 
  • Runtime downtime alerting moves from POC to production, closing the remaining manual monitoring gap on Boomi. 
  • Query automation and data validation reach into the M&A development stream, so data quality is checked as integrations are built rather than after they go live. 
  • High-volume EDM flows are optimized, so load windows stay stable as the company count grows. 

The longer-term direction is convergence. As each automation matures, it comes under the agentic triage and resolution layer, so that every new operating company adds data to the estate without adding proportional support burden.

Recent Cases

Invoice Delivery Agent for an EPC-Infrastructure Services Provider 
Infrastructure Services Company gets future-ready leveraging Modern Data Platform 
Accelerated product development for Hi-tech (Financial Services) Company
Scroll to Top