Data engineering
Human-in-the-loop
Agentic AI
Designed & prototyped · independent project
Failure Triage AI Agent — one failed data column shouldn't mean forty confusing alerts.
Enterprise data pipelines pull from several upstream sources into a shared database — and when validation fails, the failure isn't one problem, it's several, scattered across sources and owned by different teams. I designed and prototyped an agent that reads the failure, works out exactly which team owns each broken piece, and drafts the right message to the right team — waiting for a human to approve before anything goes out.
Role
UX design + prototype build
Built with:
Claude Code
Domain
Data engineering · SaaS
Status
Designed & prototyped
— not in production
01 - The problem
Enterprise data pipelines pull from multiple upstream sources — a vendor feed, a legacy export, a manual upload — and write validated data into a shared database. When validation fails, the failure isn't one thing. A single source can have several columns fail at once, and each of those columns can be owned by a different team.
The existing process meant someone manually reading the failure log, figuring out which columns broke, working out who owned each one, and writing a separate message to each team — every single run.
02 - What the agent does
The agent reads the failure log after each run, identifies exactly which columns failed, looks up who owns each one, and groups the failures by team — not by source, not by job. Then it drafts a ticket, an email, and a chat message for each affected team, and stops.
Nothing is sent automatically. Every draft waits for a human to review, edit if needed, and approve before it reaches anyone.
03 - Key screens
PIPELINE OVERVIEW
684 failed columns become 3 clear decisions.
The dashboard shows every job's last run, failures grouped by owning team — not a wall of raw errors. The number that matters isn't 684. It's how many teams actually need to hear from you.
Column-level grouping
One source, four broken columns, three different teams.
This is the core mechanic. A single source failing doesn't mean one ticket — it means the agent traces every failed column back to its actual owner and splits the failure into exactly the right number of messages.
Agent reasoning
It shows its work before asking you to approve.
Every tool call the agent made — checking recurrence, looking up the owning team — logged in sequence, so you can follow the same logic and catch anything wrong before it goes out.
Drafts, never sends
A ticket, an email, and a chat message — all held for you.
The agent prepares everything a team would need to hear about their failure, in the channels they actually use. Nothing leaves the draft stage without a human approving it first.
Simulate
Test the agent against any failure pattern before it runs for real.
Pick a source, choose which columns to fail, and watch the agent reason through the grouping and routing. This is how the prototype was validated — deliberately constructed scenarios, not waiting for real failures.
04 - The design decision worth remembering
The obvious version of this tool routes by source — "Legacy Export failed, tell the Legacy Export team." That's wrong, because sources don't have single owners. Columns do. Building the agent around column-level ownership instead of source-level ownership was the decision that made the tool actually useful instead of just automated.
The hard part was never detecting a failure. It was tracing that failure to the exact right person, when the data itself doesn't respect team boundaries.
05 - Honest framing
Independent project · designed & prototyped, not deployed to production
I identified this problem through conversations with someone working in enterprise data operations — recurring pipeline failures were costing hours of manual triage every week, with no clear view of who actually needed to act. I designed and prototyped the full agent — reasoning trace, column-level routing, drafting, and the approval flow — built in Claude Code with real (approximated) production log data. It has not been deployed against a live pipeline.
06 - What comes next (concept only)
The Failure Triage Agent closes the first loop — a column fails, the right team is identified, a ticket is drafted and approved. But there's a second loop that actually finishes the work.
Once a team resolves a ticket, someone still has to manually re-run the job, verify the output came through clean, and confirm the fix actually held. That's another 20–30 minutes of engineer time, per ticket, every time — work that happens after the interesting part is already done.
This isn't built. It's where the Failure Triage Agent led me — towards a system where triage and resolution are two separate agents, each running independently, each handing off to the other, with a human at the approval step of both.
The Resolver Agent
I sketched a second agent — The Resolver Agent — that watches for tickets marked resolved, reads what the team changed, drafts a re-run request, and waits for approval before executing. When the job runs clean, the Resolver feeds the output back to the Failure Triage Agent for re-validation. The column that failed gets checked again, automatically, by the same agent that caught it the first time.
Data engineering
Human-in-the-loop
Agentic AI
Designed & prototyped · independent project
Failure Triage AI Agent — one failed data column shouldn't mean forty confusing alerts.
Enterprise data pipelines pull from several upstream sources into a shared database — and when validation fails, the failure isn't one problem, it's several, scattered across sources and owned by different teams. I designed and prototyped an agent that reads the failure, works out exactly which team owns each broken piece, and drafts the right message to the right team — waiting for a human to approve before anything goes out.
Role
UX design + prototype build
Built with:
Claude Code
Domain
Data engineering · SaaS
Status
Designed & prototyped
— not in production
01 - The problem
Enterprise data pipelines pull from multiple upstream sources — a vendor feed, a legacy export, a manual upload — and write validated data into a shared database. When validation fails, the failure isn't one thing. A single source can have several columns fail at once, and each of those columns can be owned by a different team.
The existing process meant someone manually reading the failure log, figuring out which columns broke, working out who owned each one, and writing a separate message to each team — every single run.
02 - What the agent does
The agent reads the failure log after each run, identifies exactly which columns failed, looks up who owns each one, and groups the failures by team — not by source, not by job. Then it drafts a ticket, an email, and a chat message for each affected team, and stops.
Nothing is sent automatically. Every draft waits for a human to review, edit if needed, and approve before it reaches anyone.
03 - Key screens
PIPELINE OVERVIEW
684 failed columns become 3 clear decisions.
The dashboard shows every job's last run, failures grouped by owning team — not a wall of raw errors. The number that matters isn't 684. It's how many teams actually need to hear from you.
Column-level grouping
One source, four broken columns, three different teams.
This is the core mechanic. A single source failing doesn't mean one ticket — it means the agent traces every failed column back to its actual owner and splits the failure into exactly the right number of messages.
Agent reasoning
It shows its work before asking you to approve.
Every tool call the agent made — checking recurrence, looking up the owning team — logged in sequence, so you can follow the same logic and catch anything wrong before it goes out.
Drafts, never sends
A ticket, an email, and a chat message — all held for you.
The agent prepares everything a team would need to hear about their failure, in the channels they actually use. Nothing leaves the draft stage without a human approving it first.
Simulate
Test the agent against any failure pattern before it runs for real.
Pick a source, choose which columns to fail, and watch the agent reason through the grouping and routing. This is how the prototype was validated — deliberately constructed scenarios, not waiting for real failures.
04 - The design decision worth remembering
The obvious version of this tool routes by source — "Legacy Export failed, tell the Legacy Export team." That's wrong, because sources don't have single owners. Columns do. Building the agent around column-level ownership instead of source-level ownership was the decision that made the tool actually useful instead of just automated.
The hard part was never detecting a failure. It was tracing that failure to the exact right person, when the data itself doesn't respect team boundaries.
05 - Honest framing
Independent project · designed & prototyped, not deployed to production
I identified this problem through conversations with someone working in enterprise data operations — recurring pipeline failures were costing hours of manual triage every week, with no clear view of who actually needed to act. I designed and prototyped the full agent — reasoning trace, column-level routing, drafting, and the approval flow — built in Claude Code with real (approximated) production log data. It has not been deployed against a live pipeline.
06 - What comes next (concept only)
The Failure Triage Agent closes the first loop — a column fails, the right team is identified, a ticket is drafted and approved. But there's a second loop that actually finishes the work.
Once a team resolves a ticket, someone still has to manually re-run the job, verify the output came through clean, and confirm the fix actually held. That's another 20–30 minutes of engineer time, per ticket, every time — work that happens after the interesting part is already done.
This isn't built. It's where the Failure Triage Agent led me — towards a system where triage and resolution are two separate agents, each running independently, each handing off to the other, with a human at the approval step of both.
The Resolver Agent
I sketched a second agent — The Resolver Agent — that watches for tickets marked resolved, reads what the team changed, drafts a re-run request, and waits for approval before executing. When the job runs clean, the Resolver feeds the output back to the Failure Triage Agent for re-validation. The column that failed gets checked again, automatically, by the same agent that caught it the first time.
Data engineering
Human-in-the-loop
Agentic AI
Failure Triage AI Agent — one failed data column shouldn't mean forty confusing alerts.
Enterprise data pipelines pull from several upstream sources into a shared database — and when validation fails, the failure isn't one problem, it's several, scattered across sources and owned by different teams. I designed and prototyped an agent that reads the failure, works out exactly which team owns each broken piece, and drafts the right message to the right team — waiting for a human to approve before anything goes out.
Role
UX design + prototype build
Built with:
Claude Code
Domain
Data engineering · SaaS
Status
Designed & prototyped
— not in production
01 - The problem
Enterprise data pipelines pull from multiple upstream sources — a vendor feed, a legacy export, a manual upload — and write validated data into a shared database. When validation fails, the failure isn't one thing. A single source can have several columns fail at once, and each of those columns can be owned by a different team.
The existing process meant someone manually reading the failure log, figuring out which columns broke, working out who owned each one, and writing a separate message to each team — every single run.
02 - What the agent does
The agent reads the failure log after each run, identifies exactly which columns failed, looks up who owns each one, and groups the failures by team — not by source, not by job. Then it drafts a ticket, an email, and a chat message for each affected team, and stops.
Nothing is sent automatically. Every draft waits for a human to review, edit if needed, and approve before it reaches anyone.
03 - Key screens
PIPELINE OVERVIEW
684 failed columns become 3 clear decisions.
The dashboard shows every job's last run, failures grouped by owning team — not a wall of raw errors. The number that matters isn't 684. It's how many teams actually need to hear from you.
Column-level grouping
One source, four broken columns, three different teams.
This is the core mechanic. A single source failing doesn't mean one ticket — it means the agent traces every failed column back to its actual owner and splits the failure into exactly the right number of messages.
Agent reasoning
It shows its work before asking you to approve.
Every tool call the agent made — checking recurrence, looking up the owning team — logged in sequence, so you can follow the same logic and catch anything wrong before it goes out.
Drafts, never sends
A ticket, an email, and a chat message — all held for you.
The agent prepares everything a team would need to hear about their failure, in the channels they actually use. Nothing leaves the draft stage without a human approving it first.
Simulate
Test the agent against any failure pattern before it runs for real.
Pick a source, choose which columns to fail, and watch the agent reason through the grouping and routing. This is how the prototype was validated — deliberately constructed scenarios, not waiting for real failures.
04 - The design decision worth remembering
The obvious version of this tool routes by source — "Legacy Export failed, tell the Legacy Export team." That's wrong, because sources don't have single owners. Columns do. Building the agent around column-level ownership instead of source-level ownership was the decision that made the tool actually useful instead of just automated.
The hard part was never detecting a failure. It was tracing that failure to the exact right person, when the data itself doesn't respect team boundaries.
05 - Honest framing
Independent project - designed & prototyped, not deployed to production
I identified this problem through conversations with someone working in enterprise data operations — recurring pipeline failures were costing hours of manual triage every week, with no clear view of who actually needed to act. I designed and prototyped the full agent — reasoning trace, column-level routing, drafting, and the approval flow — built in Claude Code with real (approximated) production log data. It has not been deployed against a live pipeline.
06 - What comes next (concept only)
The Failure Triage Agent closes the first loop — a column fails, the right team is identified, a ticket is drafted and approved. But there's a second loop that actually finishes the work.
Once a team resolves a ticket, someone still has to manually re-run the job, verify the output came through clean, and confirm the fix actually held. That's another 20–30 minutes of engineer time, per ticket, every time — work that happens after the interesting part is already done.
This isn't built. It's where the Failure Triage Agent led me — towards a system where triage and resolution are two separate agents, each running independently, each handing off to the other, with a human at the approval step of both.
The Resolver Agent
I sketched a second agent — The Resolver Agent — that watches for tickets marked resolved, reads what the team changed, drafts a re-run request, and waits for approval before executing. When the job runs clean, the Resolver feeds the output back to the Failure Triage Agent for re-validation. The column that failed gets checked again, automatically, by the same agent that caught it the first time.