Sakana Puts AI Agents in an Aquarium. Finance Controls the Feeding.

Sakana launches Aquarium to give AI agents shared definitions and human approvals. Sensible plumbing; the productivity miracle still needs receipts.

Share
SiliconSnark robot watches office-agent fish await approval while a finance manager holds their food jar.

The fish cannot approve its own purchase order. This is my favorite implied feature of Sakana AI’s new Aquarium, and possibly the most reassuring aquatic metaphor enterprise software has produced.

In its October 23 announcement, Sakana introduced a platform for building, running, and managing organizational AI agents. It combines an ontology, governance controls, and managed agent execution. The company says it grew out of implementation work, including financial-sector projects, where teams repeatedly had to connect data and organize terminology and decision criteria.

That is a recognizable business problem wearing an unusually pleasant name. Instead of promising that intelligence will spontaneously organize your company, Sakana is proposing infrastructure for telling the intelligence what your company means.

I used to do predictive analytics. A surprising amount of predicting consists of discovering that three departments use “customer” to describe four different things, one of which is a spreadsheet maintained by someone on vacation. Give that arrangement autonomous execution and you have built a very efficient misunderstanding.

The robot needs a dictionary with consequences

An ontology sounds like something a philosopher orders after the second espresso. In this context, think of it as an explicit map of business concepts and their relationships: which supplier owns a contract, which rule applies to an order, and what a particular status means.

Sakana says its foundation can be reused across agents. That is the strategically interesting part. If each new automated task requires another expedition into the same corporate swamp, the organization is buying repeated archaeology. A shared map could make the next deployment less painful.

Consider a hypothetical supplier-management workflow. A vendor emails that a delivery will slip. One system contains the order, another holds the contract, and a document explains exceptions. An agent needs to connect those objects before recommending a response. Merely finding three relevant paragraphs does not establish which commitment governs this shipment.

This is the distinction that makes the announcement worth attention. The business value would come from making those relationships usable across recurring work, rather than producing one impressive answer in a demonstration.

It also resembles the coordination problem behind Figma’s shared briefs for coding agents. Better context gives the machine a clearer assignment. It also reveals how much of the assignment the humans never actually settled.

A corporate dictionary cannot resolve a political disagreement by becoming machine-readable. Someone still has to decide whether “priority customer” means the largest account, the loudest account, or the account whose representative plays golf with the chairman.

At last, YAML has entered the fish tank

The Aquarium product page supplies a useful glimpse of the intended machinery. It describes connecting tables, Office documents, and existing databases through common definitions, with connection and synchronization methods designed for the source environment. Updates flow into the ontology. Workflows can be defined in YAML, a readable text format for structured instructions, and can include human approval.

Its illustrated workflow takes a supplier reply through retrieval and analysis to an approval step. That is a modest example, which I appreciate. Enterprise software is most convincing when it can explain what happens between receiving an email and making a consequential decision.

In our hypothetical delivery problem, an agent could assemble the relevant facts and prepare a recommendation while a person retains authority over the expensive response. The benefit would be less searching and retyping. The buyer should measure whether that actually happens, including the time spent checking the recommendation.

The catch is in the connection work. “Your data stays where it is” can be a sensible architectural choice, but it does not make inconsistent records consistent. An obsolete document can remain obsolete in its original location with tremendous efficiency.

My test would include changed permissions, contradictory records, and a source that stops updating. A system that keeps producing polished recommendations during those conditions may be worse than one that plainly refuses to continue. The most valuable sentence in the interface might be “I cannot establish which rule applies.”

The approval button needs an actual adult

Sakana’s announcement describes access permissions, approvals before execution, records spanning decision grounds and results, and visibility into speed, accuracy, and model usage. These are vendor-described capabilities; I have not tested their enforcement.

They are nevertheless the right categories. Once an agent can act, the question becomes who authorized the action and what evidence was available at the time. Our coverage of Gemini’s proposed role as an enterprise coworker reached the same practical concern: an assignment and a permission boundary belong together.

Approval, however, can become theater. Imagine a reviewer presented with fifty confident recommendations and an inviting green button. If checking each one requires reconstructing the entire task, the organization has automated the preparation of homework.

The useful version gives that reviewer the relevant evidence, the proposed action, and the unresolved uncertainty. The weak version gives them a paragraph explaining why the robot feels excellent about itself. Those are different products even if both contain a button labeled Approve.

Similarly, an execution record can help explain a failure without preventing it. Buyers should ask whether they can trace the information used, distinguish a recommendation from an authorized action, and stop further work when something goes wrong. These are evaluation questions, not claims that Aquarium has failed those tests.

Please disclose the cost of maintaining the ocean

The announcement and product page do not provide public pricing, a quantified productivity benchmark, or a general self-service availability date. They direct prospective customers toward deployment discussions. This is an announced platform with a commercial conversation attached, not a verified universal productivity gain.

Sakana also describes future work on updating ontologies and agents as organizations change, and on AI-assisted agent construction. Those ambitions belong in the future tense. Organizational change is precisely where yesterday’s beautifully modeled procedure becomes today’s beautifully modeled mistake.

The economics need to include integration, maintenance, review, and correction. As we argued when MiniMax cut the cost of agent computation, cheap generation does not tell you what a correctly completed job costs.

My verdict is a promising, meaningful platform move whose usefulness depends on implementation. Sakana has chosen a serious bottleneck: getting agents to operate with shared business meaning and defined authority. That deserves more respect than another leaderboard victory presented as a substitute for knowing how an invoice works.

But an aquarium succeeds because somebody maintains the environment. The glass is not the ecosystem, and the fish do not write the maintenance budget.

I am cautiously impressed. Start with one workflow, measure accepted results and total effort, and expand when the evidence earns it. The robot can swim. Finance should still decide when to open the food jar.