Scaling with Infinite Tool Complexity: Aomi Apps

Aomi6 min read·Just now

Press enter or click to view image in full size

Announcing Aomi Apps Ecosystem: Announcing Aomi Apps Ecosystem: Aomi just became a platform of agentic applications. You can access Binance, Polymarket, Bybit, Kalshi, and more. Or build your own app.

Many problems in AI engineering are verticalized — Harvey for law, Sierra for customer service, Abridge for healthcare. Harvey’s agents read hundreds of pages, ground their output in citable case law, compare across Word docs, and apply redlines. Sierra holds a coherent customer-service conversation across turns while taking actions in systems of record. Abridge turns long clinical encounters into a structured note a physician will sign.

These domains involve long context, complicated workflows, and state that flows from raw text to structured output.

Crypto AI doesn’t look like that. What Aomi solves is blockchain execution, which has a different shape of complexity. Operations on-chain are real-time, performance-critical, and security-critical — a swap quote that’s 30 seconds stale on Hyperliquid is already 2–5bps off the market. Between blocks, millions of things happen on-chain and off-chain — Polymarket matches its orderbook, Hyperliquid liquidates positions, Across relays cross-chain intents. At settlement time, infinite possibilities open up, each manifesting as an execution route behind an API.

This is the nature of financial settlements. At settlement time, agentic complexity comes from an explosion of tool surface, not long-horizon workflows. You can’t build a single crypto agent that enlists every API as a tool inside a limited context window — so the solution is to divide and conquer, decompose and orchestrate.

Tightening Core

As aspiring AI devs with deep EVM experience, we’re close to solving the on-chain portion. Starting with basic EVM function wrappers, we iterate and eval relentlessly to get to a tightly-scoped, highly-specialized set of tools — the agent only sees the read and write primitives, and the runtime absorbs the complexity underneath. The evm-core namespace today is ten tools:

impl ToolNamespace for EVMCoreNamespace {
    const NAME: &'static str = "evm-core";

    fn get_tool_names() -> &'static [&'static str] {
        &[
            "get_time_and_onchain_context",
            "brave_search",
            "encode_and_call",
            "get_account_info",
            "get_contract",
            "sync_chain",
            "simulate_batch",
            "stage_tx",
            "commit_eip712",
            "commit_txs",
        ]
    }
}

Aomi is prompted to be “Claude Code on-chain” — reading, writing, staging, and committing batches of artifacts. The simulation step is like CI verification in coding. On our internal benchmark, tool calls to finish the same swap dropped from ~10 to ~4 as we tightened our core.

Exploding Edges

What’s troublesome is the off-chain half. There are hundreds of liquidity aggregators, thousands of APIs, billions of dollars in proprietary orderbooks. Aomi will never be competitive for end users if we stay stuck on-chain. We announced a collaboration with our beloved friend Khalani in March; every week since, another solver network has shown up wanting in — an exploding integration surface. How do we let Aomi scale in a space that keeps expanding?

Solutions

Trial one

We built a version of the DeFi agent with internal tool aggregation. We combined the routes of LiFi, Khalani, 0x, and 1inch, then unified their quote schemas. The system ranked them internally when the agent called a tool like offchain_quote(in, out, amount). A lot of projects do the same thing on the analysis side: find_token_info(usdc) internally aggregates info from DefiLlama, CoinGecko, CoinMarketCap.

Since the rise of the AI × crypto sector, agentic products are becoming the main customers of these aggregators. There’s no moat in positioning ourselves as tool wrappers, and endless aggregation doesn’t scale. We can’t be opinionated about the routes we support. Packing APIs into a single tool doesn’t do the networks justice — we can’t fully leverage the API features each vendor offers.

Trial two

Instead of aggregation, we decoupled tools into separate sets by namespace. Aomi is built with harness / application layer decoupling — an application (or agent) can dynamically load a namespace. Back to the DeFi example: we have an evm-core namespace, which is a set of tools that read and write on-chain. In trial two we also had an aggregator namespace with selected DeFi APIs; a token-info namespace with CoinGecko, CoinMarketCap, CoinAPI; a prediction namespace with Polymarket and Simmer API.

This solves tool bloat, but it’s still not good enough. We’re limited in the logic we can compose, and the runtime stays opinionated about composition. Aomi’s goal is to build an agentic Linux kernel — load any application with user-defined prompts, tools, skills, and guards.

Trial three

We stripped the app layer out of the runtime entirely, and dedicated one app per vendor that leverages its full service.

Take Khalani as an example. Instead of cramming their service alongside LiFi and 1inch, we compile a dedicated Khalani app with the aomi-sdk — a Rust program with a Khalani API client that complies with Khalani’s full API spec, wrapped as agentic tools with prompts and workflows tailored to the Khalani use case. Users can leverage Khalani’s services fully, and Khalani engineers can and should modify their app’s implementation.

On the backend, our runtime loads the app as a Linux executable (khalani.so or khalani.dylib), then the aomi-sdk relays tool calls over FFI. In crypto tech lingo: this is similar to how chains like Cosmos or Arbitrum Nitro support multi-VM through Wasm, or how zkVMs like Succinct or RISC Zero run a prover over the RISC-V instruction set — the runtime loads a program compiled to a defined binary interface, then executes it.

From the user’s perspective, you select a target app in the UI or CLI (aomi chat "buy 1 ETH" --app khalani). Aomi's implementation enforces zero constraints. There's no one-size-fits-all DeFi agent — there are only users who want specific routes.

Bad UX? Who’s the user?

You may ask: wouldn’t this increase UX friction? Retail traders don’t know what to use — why are we letting them choose? But we think the future of trading is agentic. Although Aomi supports users picking the Khalani app from the UI, the API is primarily designed for agents — which are better at ingesting text — and for developers who have opinionated strategies and want to build their own apps.

In this post, we demonstrated how to access the Aomi CLI from Claude by installing a skill — Claude handles app selection while you just say “find me the best routes to sell ETH”. In this one, we built a delta-neutral funding bot with the Aomi TypeScript client, encoding the funding-rate and liquidation rules in deterministic code while letting Aomi handle real-time on-chain solving.

So the user stories on Aomi are:

You know exactly that you want to use Khalani — you come to chat.aomi.dev and select the Khalani app.
You access Aomi through the Claude skill: npx skills add @aomi-labs/skills — and you ask your Claude, use Aomi to find the best off-chain or on-chain routes to sell token X.
You’re a developer who knows exactly what you want — you short ETH through Khalani and swap back into a Balancer pool. You build your own app with the aomi-sdk, deploy to our runtime, and access it from your custom frontend (e.g. a Telegram bot).

Calling for Developers

Since the announcement of Aomi Apps, we’ve had a handful of developers building really cool applications. Some compose actions in interesting ways; others come with beautiful dashboards built on our component library.

kuroko — an AI hybrid trading platform for prediction markets, by @0xgordian.
aomi-trader — a Hyperliquid trader that watches live BTC-PERP price action and executes trades, by Julian Martinez (@j_dev28).
orca — autonomous arbitrage on Polymarket, driven by plain English, by @DecentralDev_.

View Orca demo here: https://youtu.be/b8aPweQHPL0?si=g-ovLE4ttpHMUJVe

aomi-polymarket-demo — Jupiter Perps AI: never get liquidated in your sleep, by @funshoakinbile.

The future of applications is agentic. Agentic applications should be customizable, composable, and ready for integration into a deeper agentic stack. We’ll see the recursive complexity of Claude wrapping Qwen 3.5 replying to some Hermes agent — all making non-deterministic moves in concert, powered by their own verticalized harnesses.

This is what scales in a world of infinite tool complexity.

Try it out → https://chat.aomi.dev/

Build your own app → https://github.com/aomi-labs/aomi-sdk