Why We Built SentientWorks Starting from the Operations Side

The standard origin story for a B2B software product involves engineers who got frustrated with something technical and built a better version. That is not where SentientWorks came from. It came from spending time with operations teams at growing companies and repeatedly seeing the same pattern: capable people spending large portions of their week doing work that should not require their judgment, and using tools that were not built for what they were doing with them.

This is not the usual founder-market-fit story. I want to be specific about what we observed, because it shapes every decision we have made about what the product does and does not do.

The thing that kept happening

The pattern appeared in different companies with different software stacks, but the shape was the same: the operations team had more work than the headcount to do it, the work that consumed most of the time was repetitive and rule-driven, and the tools available were either too simple (trigger-action automation that broke when conditions got complex) or too technical (workflow automation platforms that required an engineer to configure and maintain).

The specific texture of the work varied. At one company it was accounts payable: matching invoices to POs across three systems, routing exceptions to the right people, and updating the AP ledger with the results. At another it was month-end close data assembly: pulling transaction records from five systems, reconciling account balances, and generating the close reports on the third business day. At another it was vendor onboarding: gathering compliance documentation, running the required checks, and updating the vendor master record when everything cleared.

In every case, the person doing this work was smart and the work itself was not complex. The problem was that it was not automatable using the tools available to them without significant engineering involvement, so it remained manual. And because it remained manual, the ops team's capacity was consumed by it, leaving less time for the things that actually required their judgment and relationship skills.

Why existing tools were not solving it

The tools that were available fell into two categories. On the simpler side were trigger-action platforms that worked well for two-step automations but struggled with the multi-step, conditional, exception-handling workflows that back-office processes actually require. Teams would build Zap chains that worked for the happy path and then handle exceptions manually, which meant the tool was reducing labor on the easy cases while leaving the hard cases, which were also the most time-consuming ones, entirely manual.

On the more capable side were enterprise workflow automation platforms that were designed for IT organizations, not operations teams. Configuring them required developer time that the ops team did not have access to on demand. When a business rule changed, updating the workflow required filing a ticket and waiting for an engineer. The ops team had visibility into the process outcomes but not into the process itself, which created accountability gaps when something went wrong.

What we did not see was a platform designed for the operations team as the primary user: one that was capable enough to handle the complexity of real back-office workflows, accessible enough for the ops team to configure and modify without engineering support, and transparent enough to produce an audit trail that the team could actually use when questions came up.

The design decision that shaped everything else

The most consequential decision we made early on was that the run log is not a developer tool. In most automation platforms, the execution log is a debugging interface: it tells you whether steps succeeded or failed, and it is designed to help an engineer diagnose what went wrong. It is not designed to tell a manager what the agent decided on a specific invoice, or to give an auditor a traceable record of how a particular reconciliation decision was made.

We decided the run log should be the primary interface for the operations team, not for the developer. Every step is labeled in operations vocabulary, not engineering vocabulary. Every decision step records the rule that was applied and the data that drove it. Every exception includes the log for that specific record so the reviewer understands why the exception was generated without having to go back to the source system.

This decision shaped a lot of what came after. It pushed us toward designing workflow definitions in terms that a non-developer can read and modify. It pushed us toward exception handling that routes records with context rather than routing them as opaque failures. And it pushed us toward building the audit export capability as a first-class feature rather than an afterthought, because we knew early on that the people who would need to use it would not have time to wait for an engineer to pull the data.

What we are not

We are not a general-purpose workflow automation platform for every business process. We are specifically built for back-office operational workflows: the reconciliation, close, vendor management, and compliance documentation processes that operations teams do on a recurring schedule and that require multi-step conditional logic with exception handling and audit trails. Trigger-action automation and enterprise IT workflow platforms are both better tools for the problems they were designed to solve. We are built for the category that falls in between.

We are also not a no-code platform in the sense that you can configure any workflow through a drag-and-drop interface without understanding what the workflow does. Back-office workflows have enough complexity, especially around exception handling and business rules, that abstracting away the logic tends to create hidden fragility. What we have built instead is a workflow definition layer that is readable and modifiable by a technically literate operations professional without requiring a developer, while still exposing the actual rule logic rather than hiding it behind visual abstractions.

What has changed and what has not

We started building SentientWorks in early 2023, and the core problem we are solving has not changed. The underlying AI capabilities have advanced significantly since then, which has expanded what is possible in terms of document understanding and natural-language business rule specification. But the fundamental design goal, building a workflow automation platform whose primary users are the operations team that owns the process, not the engineering team that builds the tooling, has remained constant.

The feedback we get most consistently from teams using SentientWorks is not about the automation speed, though that matters. It is about visibility. Operations managers tell us that for the first time they can actually see what the automated process is doing, rather than trusting that it worked because no one raised an alarm. That visibility is what changes how teams relate to the automation: instead of monitoring it anxiously, they can review the run log periodically and have confidence that the process is working and auditable. That was the goal from the beginning, and it is still the test we hold our work to.