AI workflow automation: what to automate first

AI workflow automation is software running a multi-step process on its own, with a model making the judgment calls that used to need a person. Search the phrase and you mostly get tool lists. The decision that actually determines whether the work pays off is not which tool you pick. It is which workflows you automate.

There are two answers, and they are not the same business. One is back office: the GitHub chores, the sales handoffs, the marketing sends, the work people already wire together in Zapier and n8n. The other lives inside your product, in the path your customer is waiting on. Both are called workflow automation. Only one of them is a product.

Trigger.dev has been on both sides of that line, publicly and expensively. The company went through Y Combinator's Winter 2023 batch pitched as Zapier for developers, spent 2 years without product-market fit, and now says over 90 percent of its usage is agent workflows. In a YC Root Access interview, two of the company's four co-founders, Matt Aitken, the CEO, and Eric Allam, the CTO, walked through where the line sits and what it cost them to find it. They announced a $16 million Series A led by Standard Capital in December 2025.

The two kinds of AI workflow automation

The first kind serves your team. In the founders' words, the early Trigger.dev use cases were the ones "a lot of people use Zapier for": internal teams building tools, automating GitHub, running marketing sends, wiring up "biz ops and sales and marketing". Useful work. It makes your existing people faster.

The second kind serves your customer. It is the workflow that fires because a user did something and now expects a result: process this document, encode this video, generate these variants, review this file. As it gets framed in the interview, it is "in the hot path of your like app that provides value directly to your users". Then the sharper half of the sentence: "Not providing value to your team."

That distinction is the whole article, and Trigger.dev learned it the slow way. Version one was Zapier for developers. Version two, a few months after the batch, was an SDK for adding async tasks to an existing product, but customers still ran the code on their own infrastructure. Version three, shipped in June 2024, was the SDK plus the platform plus the infrastructure, with Trigger.dev executing the work.

Versions one and two did not fail. They did something worse, which is that they half worked. "It did okay, but it definitely wasn't like product-market fit," the founders said. Their read on why is the line worth stealing: "I think the market was there, but the product didn't really match." Real demand plus a product that only partly solves the problem is the most expensive position a startup can occupy, because it generates just enough signal to keep you there. Growth followed version three, and once they started charging, revenue grew by more than 30 percent month over month for a long stretch.

Back-office automation is real leverage, and it is not a product

Do not read the above as a reason to skip internal automation. The case for it is strong and getting stronger.

A Y Combinator video on how the best teams now operate makes the maximal version of the argument: "Right now, the best teams aren't automating one or two internal functions. They're automating all of them." It profiles GigaML, whose internal agent Atlas expanded what each engineer could take on enough to win DoorDash as a customer against far larger competitors, and Feathr, a 12-person accounts-receivable startup that has "avoided hiring a design person at the company so far to date" by having its engineers build front-end designs with AI tooling. That is the revenue per employee argument made concrete, and the plumbing under it is the internal AI infrastructure a startup builds once and reuses.

There is a serious counterweight, and it comes from investors watching the same companies. On the a16z Show, the observation is that at genuinely good companies most resource devotion goes to product and new things rather than to automating the way the company is run, and that the more mature companies are the ones better suited to automating their internal operations, precisely because they are slower. Both things are true at different stages. Internal automation buys you payroll you do not spend. It does not buy you a product, and a small team can absolutely spend its best quarter building beautiful internal tooling for a product nobody wants.

There is also one workflow that came up as off limits. Asked in a YC session what they would never automate, the answer came back immediately: "Talking to customers." The reasoning given was that it "kept me focused on what was important" and it was the thing that meant being the person closing the loop with all the context on what to build. Automate the reporting on customer conversations. Do not automate the conversation.

Why in-product AI workflows break in production

The reason in-product automation is harder is not the model. It is duration.

A demo is a request and a response that finishes in seconds. A real workflow processes a batch of assets, calls a model several times, waits on an approval, and can run for hours. The founders point at the mismatch directly: the industry's shift to serverless over the previous 10 years made that harder, because serverless is good at short request and response work and "not very good for long-running tasks". That gap is the entire market for durable execution.

So the requirements list for an in-product workflow is longer than founders expect on day one:

• Queues and retries. A step that calls a flaky API needs to survive that API, not surface the failure to your customer.
• Idempotency. If a step runs twice, it must not charge a card twice or send a duplicate email. This is the failure mode that turns a reliability bug into a support incident.
• Pause and resume with state intact. The founders describe the goal as freezing "the whole state of the computer, the CPU, the memory, the file system", then resuming later with everything still there. The alternative, rehydrating all that state manually, is where most homegrown implementations rot.
• Observability per run. When a customer asks why their job produced the wrong output, you need the trace of that specific run, not aggregate logs.

One detail from their version two is worth sitting with. They asked customers where the code was executing, on Trigger.dev's infrastructure or their own. Roughly 60 percent thought Trigger.dev was already running it. Customers had assumed the harder half of the problem was solved for them, which is usually a signal about where the product boundary belongs rather than a misunderstanding to correct.

The security version of the same point is worth a founder's attention, especially once a workflow gets the full power of a machine and can snapshot it. A checkpoint that captures memory and filesystem is also a checkpoint that can capture credentials and customer data, and it lives somewhere with a retention policy you should be able to state out loud. Scope the machine image to the narrowest thing that does the job, keep secrets out of the snapshot, and log which runs touched which customer data. That is the same reasoning behind running a self-hosted AI agent when the workload justifies it.

Design the pause in, not around it

The most portable idea in the interview is a two-part model of what an agent workflow actually is. "There's kind of two parts to building successful agents," the founders said: "There's the like context that you need, and then there's the actual like the moment where you're doing something with that context."

Most teams build the second part and improvise the first. The gathering phase (loading the customer's files, classifying them, pulling the relevant history) is treated as setup, when it is usually where quality is decided. Getting that layer right is context engineering, and it is the difference between a workflow that improves with more customer data and one that degrades.

Between those two parts is where the human belongs. "Human in the loop, by the way, is a like a critical part of that," the founders said. The mechanic they describe: "you have this thing running, and then it can pause and ask for feedback. It could be from a human, it could be from another agent."

Notice that the approver does not have to be a person. The design rule is to put the gate at the point of no return, not at the end of the run. A workflow that finishes and then asks a human to approve the output gives the reviewer nothing to redirect. A workflow that suspends before it spends money, sends an external message, or writes to a system you cannot roll back gives them a real decision. MagicSchool, an education platform whose tools help teachers with lesson planning and marking, is one of the customers running its agent workflows on Trigger.dev.

Your documentation is now an interface for agents

One shift in the interview deserves its own line item on your roadmap. "There's the human user who wants to build something but also like the LLM is a user of trigger," the founders said, and the question they now ask internally is "how do we get LLMs to love using trigger and like choose it".

What they did about it is concrete and copyable: they built an MCP server, and they rewrote their documentation to work for agents and skills rather than only for humans reading a page. They also credit being open source under Apache 2 as a structural advantage here, because "we have a much bigger footprint on the internet than if we were closed source", and customers can point a coding agent at the repository and its tests instead of filing a support ticket.

Two second-order effects came out of that work. First, the gap they used to see between experienced developers and people who had never written software before has mostly closed, partly because the coding agents improved and partly because they made the product easier for agents to use correctly. Second, they think support is still rising but rising more slowly than customers, executions, and revenue, with the lines starting to diverge.

The current limit is the account. AI recommends the product, but a human still has to complete the sign-up flow. If your onboarding assumes a person with a browser, an agent evaluating tools on a developer's behalf will route around you. This is the same competitive surface as AI developer tools generally: the buyer you are optimizing for may not be the entity making the choice.

The bottleneck moved to review

The last thing that changes when workflows get automated is your own team's shape.

After the round, Trigger.dev cut back its engineering hiring plan, with the founders estimating productivity per engineer at "5x, 10x what it was before". They are still hiring, just far less aggressively, and the recent moves have been outside engineering: they hired a developer relations person and have a content engineer role open. That is the pattern showing up across the AI-native companies we cover, and it is the same reason orchestrating a fleet of agents has become a distinct skill.

But the constraint moved rather than disappeared. "Our bottleneck right now is actually more on the review side," they said. Generating code is cheap. Quality control, de-slopping, and user experience review are not. Three practices they use to keep quality up:

• A strong design system. "You don't want AI to create like the component from scratch each time." Give the agent good components to assemble rather than a blank canvas.
• Tests as the success signal. They went from few tests to many, written alongside back-end features, because "the agent needs to know if it succeeded". Verifiability is what lets you run the loop unattended.
• Layered code review tooling. They combine several review tools depending on the kind of change, rather than trusting one.

Their hiring process encodes the same belief. A late interview stage is a paid trial day where candidates use the tools they normally use, and someone who is not using AI tools well does not get hired. "That's the skill now. That's the actual job," they said, describing it as "the absolute opposite of LeetCode interviews". Their broader point is that the highest-value use of agents is not producing code but doing the work around it: benchmarking an alternative library before adopting it, checking production behavior before a change, running the analysis you would previously have skipped because it cost a week.

What to do this week

• Sort your automation backlog into two columns. Internal chores in one, customer-facing workflows in the other. Do not let the two share a roadmap, a budget, or a reliability bar.
• Pick one internal workflow with a documented process and a cheap failure mode. Report generation and first-pass triage are good candidates. Ship it, then measure whether it actually removed hours.
• Find the one place in your product where a user waits. That is your first in-product workflow. Write down what it needs: retries, idempotency, a pause point, and a per-run trace.
• Put the human gate before the point of no return, not after the run finishes. Anything that spends money, sends external communication, or writes to an unrecoverable system needs an approval step that can redirect the work.
• Write your docs for an agent. Add the machine-readable entry point, make sure a coding agent can get from your landing page to a working example without a human, and check whether an agent could sign up.
• Name what you will never automate. For most founders that list starts with talking to customers. Write it down before the automation backlog decides for you.

Deciding what to automate, in which order, and where a person stays in the loop is the operating question underneath all of this. Building that as a system rather than a pile of one-off scripts is exactly what the AI Operating System for Startups course teaches, and the wider map of where automation fits alongside product, pricing, and team is in our guide to AI for startups.

Sources

• From Zapier for Devs to Powering 90% AI Agents (YC Root Access), the interview this article distills.
• Profiles: Matt Aitken, co-founder and CEO, and Eric Allam, co-founder and CTO, of Trigger.dev (Y Combinator, Winter 2023).
• Funding: Trigger.dev's $16M Series A announcement and Standard Capital's note on leading the round.
• The New Way To Build A Startup (Y Combinator), for the case that the best teams are automating every internal function, and the GigaML and Feathr examples.
• The New Rule for Picking AI Winners (the a16z Show), for the counterargument that the best companies still put most resources into product rather than internal automation.
• What Actually Makes A Startup Durable (Y Combinator), for the answer on what founders would never automate.
• Customer example: MagicSchool, and Trigger.dev's MagicSchool customer story.