AI trading agent infrastructure: inside Neleus
Anupam Shah co-founded Neleus, a Rust stack that lets autonomous agents trade perpetual futures. He ran the capital, regulatory and investor side; Aurel Shin wrote the engine and owns all three repositories. This page is a teardown of the engineering, not a claim on it.
- Our role
- Co-founder — capital, regulatory, BD
- Sector
- Autonomous trading agents
- Venues
- Hyperliquid, Polymarket, Lighter
- Published
- PyPI and crates.io, Apache-2.0
Three markets, one adapter each
- Hyperliquid perpetual futures
- Polymarket prediction markets
- Lighter
Memory that can be proved, and four refusals
- Content-addressed Merkle-DAG store for agent memory
- Risk and execution core with independent refusals
- Backtester run before anything reaches a venue
Autonomous, and bounded
- Multi-agent orchestrator
- Signal ingestion hub
- Published to PyPI and crates.io
The proof lives in the store rather than in a log written beside it, so what an agent knew at decision time can be reconstructed rather than trusted.
Neleus is a Rust codebase that trades on three venues, with a signal hub, an orchestrator supervising several strategy agents at once, a backtester, and a risk and execution core. Alongside it sit a Python toolkit, a server that exposes its market and trading tools to coding agents, and a separately published storage engine built for agent memory. Aurel Shin wrote all of it.
Two questions make it worth reading. What has to be true before a model is allowed to send an order — answered four separate ways. And how you prove afterwards what the agent knew when it decided — answered by making the storage layer itself the evidence, rather than a log kept beside it.
Four independent refusals sit between the model and a live order
Each mechanism refuses for a different reason, at a different layer, and none of them depends on the model behaving. An agent that is confidently wrong trips them the same way a broken one does, which is the point: confidently wrong is the failure a prompt cannot catch.
The tool surface splits in two. Reading markets, order books and documentation needs no credential and is safe to expose broadly; anything that places, cancels or moves money needs a key the operator supplies on purpose. One environment switch puts every tool on testnet, so nothing real moves during development.
- No signing key, no order. The trading tools are unreachable without a deliberate credential.
- A circuit breaker halts execution after repeated failures in a rolling window.
- Position risk limits ship with real defaults, not a note to tune them later.
- The store refuses the write that breaks policy, rather than recording that it happened.
The proof lives in the store, not in a log beside it
The memory layer is content-addressed. Every version has a hash, a query can be pinned to a past state, and a retrieval result can be checked offline by someone who does not trust the operator. It can also prove absence — that an agent did not hold a document — which is usually the harder question.
Two details show real security work. Search relevance is scored per tenant, so a score cannot quietly reveal that documents exist which the caller may not see. And the project documents a leak it has not fixed: search timing can still depend on hidden data. Nothing forced that disclosure.
Claims that outrun the repository are the ones that get found
Three different products carried the same name. The site metadata described an intelligence layer for trading agents; the copy on the same site sold a release pipeline for trading agents; the investor material described a risk and underwriting engine for financial agents. The third had no code behind it anywhere.
The marketing surface was built ahead of the product: seventeen search-targeted routes, several claiming capabilities the project itself listed as not yet implemented. The defensible work — the refusals, the verifiable memory, a benchmark that publishes its own regressions — is what the site said least about. A buyer runs the same check on you.
What to take from this if you are building an agent that touches something real
- Make the dangerous capability absent, not disabled. A missing credential has no code path; a feature flag can be flipped.
- Assume the model will be confidently wrong, not broken. Four refusals with four different triggers is coverage, not redundancy.
- Put the proof in the store, not beside it. An audit log written by the same process only proves the process ran.
- Publish the numbers where you lose. A benchmark with no losing row gets read as marketing, and the winning rows go with it.
Common questions
How do you stop an AI agent from placing a trade it should not?
With more than one mechanism, because each catches a different kind of wrong. Strongest is structural: gate the trading tools behind a credential, so without a key supplied on purpose there is no code path to an order. Around it, a circuit breaker on repeated failures, a position-risk limit, and a policy layer that refuses the action rather than logging it. Prompt instructions do not count — a confidently wrong model follows them.
What is agent memory, and why would it need to be auditable?
Agent memory is what an autonomous agent reads and writes across runs — retrieved documents, prior decisions, learned state. Auditability matters once those decisions have consequences: the question after an incident is not what the agent did but what it knew when it decided. That means a hash for every version, retrieval verifiable without trusting the system that produced it, queries against a past state, and proof of absence, not just presence.
Do AI agents need a specialised database, or is a conventional one enough?
For most agents, a conventional database with a vector extension is enough. The benchmark shows why: the specialised store bought roughly six times faster reads and paid with writes several times slower. Make that trade only for properties a conventional store cannot give at all — proof of what was retrieved and when, queries pinned to a past state, verification by someone who does not trust your infrastructure, policy enforced at write time.
Who built Neleus?
Aurel Shin wrote the engineering. He owns all three repositories and is their only substantive committer, and every technical detail on this page is his work, not ours. Anupam Shah co-founded the venture and ran capital, regulatory, business development and investor relations. We publish the split because the repositories are public and the contributor history is one click away.
The two questions Neleus answered in code — what has to be true before an agent is allowed to act, and how you prove afterwards what it knew when it decided — are the ones that decide whether an agent can be pointed at a real system, and they shape how we scope AI agent development.