Agentic finance starts with a read-only assistant

Before finance software can act, it has to answer questions, show its work, and earn permission.

The first useful finance agent may be the one that is not allowed to act.

Give it access to billing data. Ask why MRR changed. Let it build a report, expose the underlying records and export the result.

Do not let it change an invoice or cancel a subscription.

For the past decade, finance software has mostly improved through better dashboards. More filters. More drill-downs. More ways to export the data when the dashboard stops being useful.

The interface remains static. The user has to translate their question into the software's navigation.

Agentic finance changes that relationship. The system can interpret an objective, investigate the relevant data and eventually take action within a defined scope.

But it should not gain all of those permissions at once.

The credible path looks like this:

flowchart LR
	A["Static view"] --> B["Conversational analysis"]
	B --> C["Proposed action"]
	C --> D["Confirmed action"]
	D --> E["Bounded automation"]

A read-only assistant is the first real step.

The investigation starts after the dashboard

A dashboard tells you revenue fell last quarter.

The finance team still needs to understand why.

Was it churn? Lower usage? Credits? Failed payments? One large customer having a strange month?

Every answer creates another question:

Show me the customers responsible for the decrease.

Then:

Only enterprise customers in USD. Exclude credits. Separate churn from contraction.

Dashboards work well for questions we already know we will ask. A recurring metric should remain on a dashboard.

Investigations branch. The next question depends on the answer that came before it.

Today, each refinement may require a new report, a spreadsheet tab, a SQL query or a message to the data team. The finance person has to adapt the investigation to however the software was modeled.

A conversational interface reverses that work. The user describes what they want to understand. The system builds the query and returns something inspectable.

This is becoming possible because models can reason over structured data and tools like APIs and MCP can give them access to live systems. The interface can finally follow the investigation instead of ending at the first answer.

Agentic finance should be open by design

There will not be one AI interface for finance.

A finance team may analyze an export in ChatGPT, review contracts in Claude, investigate live billing data in Lago and reconcile the result in its warehouse.

The interface changes with the job.

For one-off analysis of an export, ChatGPT or Claude may be enough. In some workflows, they will be better than a native finance assistant.

If the finance team already lives in one of those tools, giving them another chat window is mostly tab inflation.

The limitation of an uploaded file is freshness. The model sees the copy it received, not necessarily the current state of the billing system.

MCP offers another route. The Lago MCP server gives compatible AI systems access to Lago's billing data and logic.

The current Lago quickstart is designed for Claude Desktop. ChatGPT also supports remote MCP-powered apps for supported plans and workspaces, although that requires a remote deployment or secure tunnel rather than the local Claude configuration.

Same protocol, different plumbing.

We are introducing native agents because the shortest path is often inside the product. We also provide MCP because using our interface should not be mandatory.

That choice is consistent with how we have built Lago from the beginning. Lago's billing core is open source and self-hostable under AGPLv3. The agent toolkit and MCP server are public under MIT.

In agentic finance, transparency cannot stop at explaining a generated answer. Teams should be able to inspect which tools an agent can call, understand its permission boundary and decide where their data and workflows run.

🔓 Lago gives you native agents without trying to own your interface.

Why we start read-only

At Lago, we separated two jobs.

The Finance Assistant is read-only. It turns plain-language questions into aggregated reports. The user can inspect the underlying data and export the full result.

The Billing Assistant can perform operational tasks. Consequential actions require confirmation.

Putting both jobs behind the same text box would have been easier to market and harder to govern.

Investigating an unpaid invoice and modifying it have different risk budgets.

The current Finance Assistant is a beta, with beta-shaped edges.

Generated reports are drafts and can contain mistakes. They are point-in-time and cannot yet be saved or pinned. Access follows the configured API key rather than each user's individual role permissions.

Those limitations belong in the product story. A correct number with unclear provenance is not a finance answer.

Users need to see where the number came from, which records were included and what the assistant is allowed to do next.

This is how a finance product earns more permission:

1. Answer the question.
2. Show the work.
3. Propose an action.
4. Ask for confirmation.
5. Act within an explicit scope.

Our prediction: by 2028, finance teams will care less about how many tasks an AI feature claims to automate. They will care more about how clearly it exposes the path from reading data to changing it.

Agentic finance will arrive one permission at a time.