Agentic Apps for Operations

In 2024, I worked with a client who wanted to introduce agents into their data function. We built a LangChain agent that put together a weekly report on the state of their business. But alongside that project, they were talking about agents helping with all sorts of operational work.

I felt a little out of my depth. I could see how to assemble an agent workflow, but I didn't have a clear picture of how to turn those ideas into applications people could use and operate every day.

Two years later, that picture is becoming clearer. Between the tools for building agents and the platforms for deploying applications, I see a growing opportunity for data platform owners to participate more directly in business operations. The review app I've been building for RepublicOfData.io is a small example of what that can look like.

From reporting to operational loops

For a long time, my mental picture of the modern data stack followed a fairly familiar path: ingest data from source systems, bring it into a warehouse, model it with dbt, and serve the results through a BI tool.

That picture expanded. Orchestration, observability and governance became more visible parts of the platform. Data science and machine learning sat alongside reporting. And reverse ETL gave us a way to feed the data we'd prepared back into operational tools.

I remember an early conversation with the founder of Census. I found the idea interesting, but I couldn't quite see where I'd use it in my own work. The useful part of that conversation stayed with me: the data platform could produce something that went back into the business's operations.

That's the connection I'm returning to with agentic apps.

An app can take data from the platform, do some further work with it, involve a person where judgment is needed, and return the result to a system. That result might be a decision, a proposed correction or a new piece of information for the platform to process.

In this view, agent infrastructure and data activation become closely related parts of the stack. One provides ways to perform work with models and tools. The other connects prepared data to the systems where work happens. An operational app can bring them together.

The application around the agent

Around the time of that client project, I was experimenting with LangChain workflows orchestrated through Dagster, with Hex as an interface for looking at the results. It was an early version of the same idea: perform some treatment of the data and feed the output back into the platform.

What interests me now is how much attention is going into the application around those workflows.

Vercel's Agent Stack, for example, brings together connections to models, workflow execution, and access to data and tools. Its open-source framework, eve, assembles those building blocks into an opinionated way to build an agent.

At Ship 2026, Vercel also described its platform as somewhere both developers and coding agents can build and deploy software, with controls over access and spending across an organization.

That combination catches my attention. An operational app needs a place to run, an interface, access to the right systems, and a way to control who can do what. The agent is one part of that application.

I haven't tested Vercel's approach enough to judge how well it fits my own platform. My interest comes from the connection between its application infrastructure and the agent stack it's assembling. I want to see what that combination changes in practice.

My expectation is that we'll see more small applications built around specific operational needs. Some will use agents to investigate or prepare work. Others will use ordinary application logic. Both can become useful participants in a data ecosystem.

A review app beside the data platform

Here's the example I've been working on.

My RepublicOfData.io platform tracks vendors and their offerings across the data stack. As it processes sources, it produces proposals that need review. I need to inspect the evidence, decide whether the proposal is supported, and record what should happen next.

I've built a separate review app alongside the platform's Dagster workflows. It takes those proposals and prepares cases for my inbox.

There are two places where agents help. During preparation, a source-assessment step checks whether assertions in a proposal are supported by the source documents. Another model considers the evidence and prepares a suggested verdict with its reasoning.

Then there's the review itself. If I have a question about the case, I can continue the conversation through a chat interface and ask for clarification or further evidence. The recommendation gives me something to inspect and challenge before I make a decision.

The basic flow looks like this:

Recording that result and applying a change to accepted data are separate steps. A recommendation alone doesn't establish a fact or authorize a change. The platform's application step belongs after the human decision, where a change has been approved.

The app shown in the video runs on my VPS and uses LangChain. It's the example I'm using to explain the pattern; the Vercel experiment is still ahead of me.

Both a consumer and a source

The part I find most useful is where this app sits in the ecosystem.

It's a consumer because it reads proposals, evidence and context from the platform. It's also a source because it produces review decisions and reasoning that become inputs to the platform's subsequent work.

That makes the interface part of an operational loop. I use it to perform a task, and the task produces data the rest of the system can use.

This connects to something Dagster changed in my own thinking. I started to see data assets more broadly than source tables and dbt models. I began asking what a piece of the ecosystem takes as input, what work it performs, and what it produces for another consumer.

Earlier, I used agent graphs inside assets to enrich data. The review app extends that idea into an application with an interface and a person participating in the process. Some of the work happens in agents, some in ordinary code, and some through my judgment. The inputs and outputs connect that work back to the platform.

Shared meaning matters here too. In my platform map, semantic context sits between the prepared data and its consumers. An operational app needs to understand what the entities, attributes and metrics mean, just as a reporting tool does. It also needs a clear purpose for the work it performs with them.

For the review app, that purpose is specific: take a proposal, prepare the evidence for review, and return a recorded decision. I can describe what the app needs from the platform and what it contributes in return.

A wider role for data platform owners

I think operational apps create an opportunity to extend the value of the data work we're already doing.

A consistent definition of a customer or a metric is useful in reporting. I'd look for opportunities to use that same context in applications that help someone investigate an exception, review a proposed change or decide what to do next.

For platform owners, the practical question is where prepared data can help complete a recurring task. I'd start with a process where someone already gathers information, makes a judgment and records an outcome.

Then I'd make the loop explicit:

• What information does the task consume?
• What can an agent usefully prepare or investigate?
• Where does a person need to make the decision?
• What result should return to the platform or operational system?

Those questions describe the application and its relationship to the data platform. They also help identify which parts need an agent at all.

What I want to test next

My next experiment is a monitoring app connected to my data platform, with Dagster and BigQuery as the starting environment. I want to build the application and its agent component using Vercel's ecosystem, then see what the managed infrastructure actually contributes.

That will give me a more concrete basis for judging the tooling. For now, the review app is enough to make the broader idea tangible: it reads platform data, helps me do operational work, and returns the result to the system.

If you own a data platform, pick one recurring task that already depends on its data. Map the input, the work, the decision and the output. That's where I'd start looking for an operational app worth building.