Why AI needs someone inside the workflow.
A powerful model does not know how your company works. Someone has to connect the technology to the people and processes behind the job.
A clip from Aaron Levie's conversation with Sequoia put words to something we see at Ruby all the time. A company can have access to a powerful model and still have no clear way to use it in the work that matters. Levie talks about the need for people who can connect the technology to a company's actual processes. Mike Fishbein shared that part of the interview and called the independent people doing this work “Indie FDEs,” or independent forward deployed engineers. That description resonates with how we approach our clients.
An AI tool can answer a question in a chat window. A workflow has to do more. It may need information from an approved source, a check against a company rule, a prompt to the right employee at the right time, and a clear handoff when the answer is uncertain. Levie's example is that a law firm, bank, or pharmaceutical company needs someone to bridge that gap between a general model and its particular business process. The same problem exists in a 50-person company, even if the tools and the budget look different.
We saw what that can look like with a private equity firm preparing its quarterly investor packages. The team had to gather spreadsheets and investor information, work through the material by hand, and put it into a new sheet for its investor check-in. That preparation took about 50 hours each quarter. Ruby came in to learn how the team handled the package, where the information lived, and how it needed to appear for investors. We helped build a process that pulls the information into the package format, bringing that preparation down to about two hours. The important change was in how the package was assembled, not just in how quickly someone could draft a paragraph about it.
That is the work we mean when we describe Ruby as an Indie FDE. We are independent of any one model provider, so our starting point is the client's process and the tools its employees already use, whether that is ChatGPT, Claude, Copilot, or something else. We learn the business with the people doing the work, map the recurring tasks and decisions, and document the context the technology needs. Then we help build and test a better way through the workflow and train employees on their part of it. The goal is for the new process to make sense during the next reporting cycle, not just in a demo.
Independence also changes how a model should be chosen. Levie argues that the person deciding which model handles a task should be able to compare cost and accuracy without favoring a particular provider. That does not mean an independent partner can always make the work cheaper, or that a vendor's team cannot do excellent work. It means the question can stay open: which tool gives this team a reliable result at a sensible cost, inside its approved systems? Sometimes the answer is a newer model. Sometimes it is a simpler workflow using a product the company already pays for.
The work continues after the first version goes live. Employees find exceptions, the business changes a policy, and the platforms add capabilities. Ruby's ongoing support is meant to bring those changes back into the processes employees actually use, so the team keeps learning rather than being handed a one-time setup. That is why this role feels important to me. AI may be moving quickly, but the value appears when someone takes the time to understand a company's people and helps them change how the work gets done.
Sources & further reading
Start with the work. Build the right system around it.
We help teams understand where AI is useful, choose the right tools for the job, and build the confidence to keep improving.
Book a Call