An employee asks: “Can you give Priya access to the staging database?”

In most companies, that simple request is not simple at all. Someone has to figure out which team Priya is on, whether the request is allowed, who needs to approve it, where the access is defined, how to update it, whether it requires a code change, how to notify the requester, and how to leave behind an audit trail.

The employee does not care whether that work happens through Slack, Okta, GitHub, Terraform, AWS, Jira, or an internal admin tool. From their perspective, they had one thing they needed done.

Serval’s job is to make it feel that way.

Someone asks for something in natural language. Serval figures out what they mean, finds the right tools, runs the automation across the systems involved, brings in a human when needed, records what happened, and lets them get back to work.

Most companies already know which workflows should be automated: access requests, onboarding, hardware requests, infrastructure changes, security reviews, approvals, CRM updates, finance operations, and internal support. They stay manual because automation is usually too expensive to create and too brittle to maintain. If a process crosses five systems, varies by team, depends on a policy that lives in someone’s head, and only happens a few times a month, it usually remains the responsibility of a human.

Serval is built on a simple idea: LLMs change the cost curve of automation. But cheaper automation only matters if it is safe to run. The output has to be structured, permissioned, reviewable, durable, debuggable, and auditable.

The ambition is specific: automate 100% of company operations, not just the easy parts. Most automation tools cover the common, high-volume workflows and leave everything unusual to a person. But the long tail of hard, rare, cross-system requests is where most of the manual work actually lives. Automating the obvious slice is not enough. The goal is to reach the messy long tail: the workflows that were always too rare, too specific, or too expensive to justify automating before.

We had to design for two distinct experiences: employees running automations, and admins creating them. An employee might ask, “Can you give Priya access to the staging database?” An admin might define that as: check Engineering membership, ask the manager for approval, open a Terraform PR that adds the IAM binding, wait for review, and notify the requester when the pipeline applies the change.

In that sense, Serval is not just automating work. It is automating the creation of the automation itself: making it fast to define the workflow, not just fast to run it after it exists.

Doing this well is hard. But we have strong conviction at Serval that if a hard technical choice gets you closer to the best end-user experience, you should take it seriously rather than route around it. A few of our early decisions came from that philosophy.

Decision 1: Build the platform, not the layer

The obvious shortcut would have been to build Serval as a thin layer on top of existing ticketing or IT Service Management (ITSM) systems: read the ticket, use an LLM to classify or summarize it, call a downstream automation, and post the result back. That would have been faster, and it probably would have produced a good early demo.

But it would not have changed the underlying architecture. The ticketing system would still own the request. Access management would still live somewhere else. Approvals would still happen in another tool. Execution state would still be scattered across logs, Slack messages, webhooks, and downstream systems. The LLM would make the existing process feel a little smarter, but the company would still be operating through the same fragmented stack.

That is the problem we wanted to solve directly. Users should not have to know which system owns a request. Admins should not have to wire together tools that were never designed around a shared model of the world. And engineers debugging a failed workflow should not have to reconstruct what happened from five different places.

The iPhone is a great product in large part because Apple owns the hardware and the software together. The experience is not assembled from loosely connected layers; it is cohesive because the pieces are designed to fit. We see the same thing in company operations. The system of record and the system of action need to be unified. If one tool stores the request and another tool executes it, the user experience, admin experience, and audit trail all fragment. So we set out to own the whole surface area, replace what legacy systems do, and then build something vastly better than what is possible with fragmented systems.

Take the Priya request. With a thin layer, you'd have a smarter ticket. But you'd still need someone to find the Terraform file, open the PR, wait for review, and notify the requester. The request would still touch five systems. Serval would just be making the first step feel easier.

Decision 2: Code as the source of truth

Owning the platform meant we had to decide what workflows actually look like inside it.

This was not obvious at the time. A lot of automation products are built around forms, visual workflow builders, decision trees, or graphs. Those can work for simple cases, but they tend to hit a wall when the workflow gets complex: call this API, branch on this policy, wait for this approval, update this record, retry this operation, open this pull request, and make the whole thing understandable later.

When we made this decision in early 2024, our view was that code was going to get much cheaper to write because LLMs were going to be good at writing it. That changed the authoring model. If workflows were often going to be authored by an LLM, they should be represented in a form the model is good at producing and humans are good at reviewing.

Imperative code is that form. It gives you standardized control flow, types, review, versioning, tests, and a way for engineers to understand exactly what will happen. Once code becomes cheap to create, deployment, execution and evaluation become the harder platform problems: making it easy to run that code in a safe, controlled, audited environment. So we built Serval around imperative TypeScript code as the source of truth for deterministic workflows, and made it as simple and secure as possible to run and iterate on that code.

Code is also what lets us target the workflows that do not fit into a predefined catalog. A fixed set of actions or a visual builder can work well for common requests, but it breaks down when the workflow is specific to one company: read this policy file, branch on this approval rule, update this internal system, open this exact pull request, and explain the result in the format this team expects.

Those are exactly the workflows that usually stay manual. A general-purpose programming model gives Serval a way to express them without waiting for someone to build a special-purpose block first.

That does not mean every procedure should be expressed as code. We also support natural language standard operating procedures called Skills, because some parts of a workflow are inherently judgment-based: interpreting what the user is asking for, applying a policy written in human language, deciding whether two requests are equivalent, or explaining why a request was denied.

Both forms matter, but they play different roles. Natural language is useful for reasoning about ambiguous inputs, interpreting user intent, and handling judgment calls. Code is the source of truth for the automation that actually runs: the deterministic, side-effecting, reviewable artifact that can be permissioned, versioned, debugged, and audited.

It also shaped how workflows run, not just how they are written. Most workflow systems expose something graph-shaped: define tasks, connect them with edges, and let the engine execute the graph. That is a good abstraction for data pipelines and batch jobs. It is not the developer experience we wanted for an AI-authored workflow system.

We wanted full control over the developer experience so the thing Serval helps author could look as much as possible like standard imperative TypeScript:

That is the point: Large language models are good at writing this kind of code, and imperative code is a very efficient way to represent logic. You get conditionals, loops, functions, types, libraries, and all the syntax programming languages have evolved to express complex behavior compactly. If necessary, an admin can review the behavior. The side-effecting work is explicit, typed, and inspectable.

Underneath, the runtime still has to behave like a long-running workflow engine. A real company workflow waits on approvals, retries failed integrations, resumes days later, and leaves behind enough state to debug what happened. We built our own durable execution engine for two reasons: to keep authored workflows as close as possible to standard TypeScript, and to have full control over the developer experience, even when the developer is an LLM. The code should use normal control flow and normal awaits, not a manually constructed state machine, while the runtime handles persistence, resumability, idempotency, visibility, and human-in-the-loop execution.

This decision has kept paying dividends. We use code-based workflows all over Serval to make the product more extensible. Our Databases product is a good example: LLM-generated Serval workflows can ingest data from external systems so Serval has a complete view of the connected tools around a customer. In practice, that turns Serval into something like an ETL pipeline plus datastore, built on the same workflow substrate we use for on-demand automations.

Decision 3: Own the integration engine and execution environment

The third decision was to own the integration engine and the environment where workflow code runs.

This sounds like plumbing, but it is what makes it possible for Serval to be a complete, universal automation platform. To automate the long tail, Serval cannot expose a small menu of prebuilt actions. It needs to understand and call the full API of each connected system: the common paths, the obscure endpoints, the permissions, the auth model, and the ways the API fails.

So we built the integration layer to do two jobs.

At runtime, it is the controlled boundary between workflow code and external systems. Workflow code can call GitHub, Okta, Salesforce, Google Workspace, AWS, Snowflake, Jira, Slack, Terraform, and other tools through approved interfaces, without ever handling raw credentials directly.

At authoring time, it is the context the Serval automation agent needs to write useful workflows against those systems. The integration layer knows what objects exist, which endpoints can be called, what scopes are required, what the request and response types look like, and what good examples look like.

We wanted security baked into the system at the boundary between workflow code and integrations. Workflow authors should be able to call approved capabilities, but they should not be able to access raw credentials from the runtime. Code runs in a sandbox we control, while the integration layer applies the right credential outside that runtime. That gives us one place to enforce permissions, observe actions, attribute what happened, and, when needed, run workflows safely in customer-owned environments.

The model can write the workflow. The platform has to make it safe to run: permissioned, durable, observable, and capable of taking action across real systems with security enforced at the integration boundary.

The bet

Serval is a bet that LLMs will cause much more code to be written to automate company operations. If that code becomes cheap enough to create and maintain, it becomes possible to automate any repetitive process inside a company. Not just the common requests. Not just the workflows that fit neatly inside an existing tool. The goal is a universal automation platform that can handle the long tail of rare, messy, company-specific requests that were never worth automating before.

That goal has shaped almost every technical decision we have made. We try not to take simplifying assumptions that make the first version easier but make the full solution impossible later. A fixed menu of actions is easier than a programmable workflow engine. A thin layer on top of tickets is easier than owning workflow state. Passing credentials into a runtime is easier than building a secure integration boundary. Exposing a DAG is easier than making durable execution look like normal TypeScript.

We chose the harder path in these places because the product needs the underlying platform to be general, secure, and reliable. If Serval is going to automate company operations end to end, the system has to be able to express the process, execute it safely, survive real-world failure modes, and keep a clear audit trail.

What does the world look like when that bet pays off? “Can you give Priya access to the staging database?” is the whole interaction. Serval checks the policy, opens the Terraform PR, routes it to the right approver, resumes when it is approved, applies the change, and tells the requester what happened. There may still be human approval where the company wants it. Priya just does not have to shepherd the request across systems or spend time clearing operational hurdles on the way to getting their work done.

That is the bar we are building toward: a platform that can take any repetitive company process and turn it into something reliable, secure, and easy to run.

If building that kind of system sounds exciting, we would love to work with you.