The database is not the operating system

For a while, I thought the hard part was organizing the data.

It wasn’t.

The database already existed. So did the Slack messages, tickets, spreadsheets, bank records, trades, contracts, customer conversations, market data and internal documents.

We had information everywhere.

What we didn’t have was a system that could keep turning that information into an updated understanding of the business after I closed my laptop.

That distinction has become increasingly important to me.

A database can tell you what is stored.

An operating system needs to help you understand what just happened, what changed because of it, what needs attention now and what should happen next.

That is a very different problem.

Companies are constantly producing events

A company generates events all day long.

A customer sends a message. A trade executes. Money arrives at a bank. A provider changes a limit. A contract gets signed. Someone moves a Jira ticket. A regulator publishes something. A salesperson learns something important during a call. A decision gets made in a meeting.

Individually, these are observations.

The interesting part starts when they can change the state of the company.

A message from a customer may mean a deal has moved forward. A bank credit may mean a transaction can settle. A failed integration test may mean revenue is blocked. A signed contract may move a customer from negotiation into implementation.

The event matters because something became different.

So I started thinking about the company in a very simple loop:

EVENT → STATE → DECISION → ACTION → RECEIPT → NEW EVENT

That loop is increasingly how I think about software, AI and operations.

History is useful. Current state is useful too.

I like event-driven systems.

I do not want to turn the company into a pure event-sourcing experiment.

There is value in keeping an immutable history.

A trade happened at a certain time. A bank transfer was received. A customer asked a question. A status changed.

Those facts should not disappear simply because the business later changed.

But I also don’t want to replay the entire history of the company every time I ask a basic question.

I want to know:

What stage is this customer in now? Is this account active now? Who owns this problem now? What is blocking revenue now? What capability does this provider actually have now?

So the architecture becomes something closer to:

EVENT HISTORY → CURRENT STATE → DECISION

The history gives us evidence. The current state gives us usability. The decision gives the system a reason to exist.

More data does not necessarily create more understanding

One of the strange things about modern companies is that we can have extraordinary amounts of information and still spend a meeting asking:

“Where are we on this?”

That question says a lot.

The information may exist. Someone may even know the answer. But the company itself does not necessarily know the answer in a reusable way.

And AI makes this problem more visible.

Giving a model access to ten thousand Slack messages is not the same thing as giving it an understanding of the business.

It still needs to know what things mean.

A human can often resolve ambiguities without noticing.

A machine cannot.

At least not reliably.

The hard problem is not giving machines more information.

It is giving information meaning.

This is where AI gets more interesting

My initial use of AI looked like everyone else’s.

Write this. Summarize that. Research something. Compare two documents.

Useful, certainly.

But not especially transformative.

The more interesting experiment started when models became capable of working across the operational environment itself.

Reading. Searching. Writing code. Querying data. Comparing evidence. Finding inconsistencies. Preparing actions. Checking what happened afterward.

That begins to look less like a chatbot and more like a new participant in the operating system.

But there is an important catch.

A model producing an answer does not mean the company has taken an action.

A model producing an action does not mean that action was correct.

And an action being technically successful does not mean it was authorized.

So we started caring a lot about receipts.

A request. An execution. A result. A timestamp. An identifier. A before and after.

The receipt closes the loop.

Without it, automation can produce an enormous amount of activity while leaving everyone unsure about what actually changed.

Humans do not disappear from this architecture

Quite the opposite.

As software becomes capable of doing more, the line around human judgment becomes more important.

There are things a machine can observe. Things it can infer. Things it can recommend. Things it can execute.

And then there are decisions that belong to people.

Evidence is not approval. A recommendation is not a commitment. A green test is not a business decision. An automated workflow is not authority.

The point is not to remove humans from the operation.

It is to remove the unnecessary distance between information and judgment.

Brazil is a good place to test this

I happen to be running this experiment inside a financial operation in Brazil.

That makes things more interesting.

Markets meet banking. Banking meets regulation. Regulation meets software. Software meets customers. Customers meet operations.

And everything eventually meets money.

There are very few clean boundaries.

Which makes Brazil a surprisingly good environment for thinking about operating systems.

You quickly discover whether your abstraction survives contact with reality.

A transaction either settled or it didn’t. A customer is either waiting or they aren’t. Money is either available or it isn’t. A price was either executable or it wasn’t.

Production has a way of removing philosophical ambiguity.

The database was the beginning

We already had Postgres.

We already had plenty of data.

That was not the destination.

The next step is turning those pieces into something continuous.

Sources produce events. Events update state. State creates decisions. Decisions create work. Work creates receipts. Receipts become new evidence.

Then the loop runs again.

And somewhere inside that loop, machines can begin doing increasingly useful work.

That is the experiment I want to document here.

Not “how to use AI at work.”

Not predictions about artificial general intelligence.

Not productivity hacks.

Mostly notes from trying to make a real company more legible to software — and software more useful to the people operating the company.

I suspect the interesting question is no longer whether companies will use AI.

It is whether they can build environments in which AI can understand enough context to be useful without becoming another source of noise.

That feels like an operating-system problem.

And we are already running it in production.

Related reading

What does it actually cost to move $10 million through Brazil? — a CFO framework for measuring what a cross-border route actually costs, not just its headline FX spread.

Teaching a machine what BRL looks like — on why a price is a structured object — venue, size, timestamp, settlement — not a single number.

Follow the money through Brazil.
ONCHAIN FX covers markets, capital, stablecoins, technology, infrastructure and the systems behind moving serious money. Get the next note in your inbox.

Subscribe

Moving meaningful volume through Brazil? Talk to us.