Senior Forward Deployed Engineer
Senior Forward Deployed Engineer
At Liatrio, being forward-deployed engineers means we spend most days sitting next to engineers doing real work. One thing we keep running into: the people most valuable to a client, the senior engineers, the architects, the folks who hold the system together in their heads, are the ones spending the most time on Day-2 operations they shouldn't be touching to begin with. A build broke on main, and someone spent most of Tuesday figuring out why. An error rate ticked up for twenty minutes on Thursday night, and someone dug through a dashboard until they understood it. Nothing about those evenings was feature work.
The way we've started to frame the problem internally: how do we take that cognitive load off the people who are most valuable at these companies? Not by replacing them with an agent. That's not where the industry is, and it's not what the clients we talk to actually want. By handing the first ten minutes of each Day-2 job to something that runs on its own, so the person who gets paged arrives with context already gathered and a plausible diagnosis to react to.
If you're reading this, you've probably had the same conversation we have with our clients. A CTO is asking for an AI story. Copilot or Cursor is rolled out to some teams and feels useful but hard to point at on a dashboard. Someone sent you a demo of an agent that catches failures and ships a fix, and it looked impressive and faintly terrifying at the same time. You're trying to figure out what belongs between where you are and where that demo lives, and you'd like it to be defensible in a security review.
What we keep seeing is that the thing that belongs there is smaller than the demo. One Day-2 job the team already does every week. Start with deterministic checks, and use the model only for the cases they can’t resolve. Nothing moves forward until there's evidence it's working. The first job we usually pick for a client is pipeline-failure triage, and the rest of this is why.
Why pipelines are the place to start
When we ask tech leads across our client base which Day-2 work keeps coming up, two jobs show up most often: pipeline failure triage, when a deployment pipeline fails after merge, and production incident triage, when an error shows up in production. Both are a reasonable first move. We've found pipelines are the cheaper of the two.
Part of it is scale. The DORA's 2025 State of AI-assisted Software Development report found that about 43% of respondents take more than a day to restore service after a change to production degrades it (Figure 13). If a build or deploy fails, someone has to decide whether it's a code bug, an infrastructure issue, or a flaky test, then route it. The job repeats weekly, sometimes daily. The signal is already captured in CI logs. The answer is usually knowable within fifteen minutes if the right context is in one place.
Part of it is honesty. Those three qualities (repeats often, cheap to check, boring to do) are what let you actually measure whether an agent is pulling its weight. It's hard to measure an agent's incident-response work when every incident is bespoke. It's not hard to measure its pipeline work when the same test flakes forty times a week.
Start deterministic, let the model handle only what rules can't
The move most teams want to make is to point an LLM at a build log and ask it to figure out what happened. We'd push back on that as the first move. We'd start with deterministic rules.
What we've seen is that most pipeline failures fall into one of three buckets: a code problem (your tests found a real bug), an infrastructure problem (a runner died, a secret rotated, a package registry was down), or a flaky test (the same code passed yesterday). Plain pattern-matching sorts a surprising amount of this correctly: stack traces, exit codes, retry history, which stage failed. On a project where end-to-end UI tests were painful to diagnose, we built a narrow skill that analyzed a failure, traced the root cause, and suggested a fix. The rules did most of the sorting. The model only ran when the rules couldn't decide.
Two things we like about this when we talk it through with a client's security team. You don't pay for a model call every time a lint fails. And when a human asks, "why did it make that call," you can show them a rule, not a prompt. Deterministic-first is how we earn the right to use the non-deterministic part.
Crawl, walk, run, and the evidence that moves between them
A lot of the reason the fully autonomous demos make engineers uneasy is that they jump straight to the end. In every engagement we’ve been in, teams gave the agent autonomy only after engineers had worked alongside it for a while and watched it get things right. We’ve found an incremental approach successful because each stage must produce something before the next can start.
In the first stage (crawl), people on the team still run the triage, but the prompt that works for them becomes a shared skill. A tech lead can hand it to a new teammate and still get a consistent answer. The sign we look for before moving on is that the skill gives the same reasonable diagnosis across a handful of real failures without a person tweaking it each time.
In the second stage (walk), the skill runs on its own when a pipeline fails, but it only reads. It queries the logs, checks whether the same test failed yesterday, looks at recent commits, and posts a diagnosis to the pull request or the Slack channel. A person reads it and decides what to do. This is where the evidence actually comes from: how often the agent is right before it touches anything, whether its access to logs and CI holds up, what a single run costs. Meta reported that an internal investigation agent cut median detection-to-mitigation time from 9.5 hours to 3.8 hours on their systems.
In the third stage (run), the same agent, with the same read access, can propose a change. It files an issue with a suggested fix or opens a pull request. Review still matters: developers merged 51.8% of fixes drafted by Uber's FlakyGuard. The gates become non-negotiable at this stage. The agent needs its own identity, not a borrowed credential. It needs a spend ceiling someone can see on a dashboard. It needs an approval step and an audit record. In our experience, most of the "we can't do this" conversations with enterprise clients are about these gates, not about model quality.
What we usually suggest for the first few weeks
When a client asks what the first move actually looks like, the version we describe is small enough to fit in a paragraph. Pick one repo or one service where the pipeline fails often enough to be annoying. Write the deterministic classifier first: three buckets, nothing fancy, no model call. Add a read-only skill that collects what a human would gather: the failing step, the stack trace, the last commit, prior failures of the same test. Have it post a diagnosis as a comment on the pull request. Nothing it writes should touch production. Nothing it reads should require a person's local credentials.
Run it for a few weeks. Count how often the diagnosis matched what actually fixed the failure. Count how much a single run costs. Watch what happens when the model is wrong: does the team learn to ignore it, or do they correct it? Those three numbers are what tell you whether to move from walk to run. Not coincidentally, they're the three numbers a CTO tends to ask for.
One honest caveat about agent factories
The pitch for a fully autonomous system that catches failures and ships fixes without a human in the loop isn't wrong in the long run. We've seen teams try to start there, though, and in those engagements the project usually bounced back to walk after the first embarrassing fix. The crawl and walk stages aren't a tax; they're where the trust gets built. It tends to be cheaper to start where you're going to end up.
What this sets up next
The reason we steer first conversations toward pipeline-failure triage isn't that it's the only use case. It's that the pattern you build (deterministic shell, read-only diagnosis, measurable walk period, gated run) is the same pattern you'll use for production incident triage, for noisy alert handling, for migration dry-runs, for most of the Day-2 work your senior engineers shouldn't be touching. Pipelines just happen to be the clearest first proof. Once a team has run this once and a security review has approved it once, the second workflow is dramatically less work than the first.
If you want to compare notes
We'd like to hear what your pipeline failures actually look like, and where the gates in your org are tightest. If your team is somewhere between "we have Copilot" and "we have an agent factory" and you're trying to figure out what to put between them, we'd be glad to trade stories. Reach out. A thirty-minute conversation is usually enough to tell whether this is useful.
See the rest of the delivery path
Pipeline-failure triage makes sense as a first agent because you can start with deterministic checks, then move from crawl to walk to run once its diagnosis holds up.
A complementary Value Stream Mapping session with Liatrio puts that job in the context of your full delivery flow, from intake through release, so you can see where work stalls and which improvements are worth making first. You walk away with a map of your current state, a prioritized list of opportunities, and practical recommendations.
