AI trading agent infrastructure: inside Neleus
Neleus is a Rust stack that lets autonomous agents trade perpetual futures on live venues. Anupam Shah co-founded it.
What follows is the architecture at the level a counterparty would want to see: what stands between a model and a live order, and how the system reconstructs afterwards what an agent knew when it decided.
- Our role
- Co-founder
- Sector
- Autonomous trading agents
- Venues
- Hyperliquid, Polymarket, Lighter
- Language
- Rust monorepo, Python toolkit
Neleus is a Rust monorepo that trades on three venues.
It carries a signal ingestion 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 exposing its market tools to coding agents, and a separately published storage engine built for agent memory.
Two questions make the architecture worth reading, and both generalise well beyond trading. What has to be true before a model is allowed to act on a real system — answered four separate ways, none of which trusts the model.
And how you establish afterwards what the agent knew when it decided — answered by making the storage layer itself the evidence, rather than a log written beside it by the same process.
What is not on this page is the strategy: the signal set, the parameters, the sizing rules. Those are the part that decays the moment they are published.
The safety architecture is the part that transfers, and it is the part a client is actually buying.
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 known side channel: search timing can still depend on hidden data.
A benchmark is only worth reading if it publishes where it loses
The storage engine was measured against a conventional store on a single-machine harness run by the project itself, not a vendor-neutral bake-off. On that harness the specialised store bought roughly six times faster reads.
It paid for them with writes several times slower.
Both halves ship together, and the second one is the useful number. A read-heavy agent that queries far more often than it writes takes that trade happily; a write-heavy pipeline should not take it at all.
A benchmark with no losing row gets read as marketing, and when a reader discounts it they discount the winning rows in the same motion.
Most agents do not need a specialised database.
Make the trade only for properties a conventional store cannot offer at any price — see AI agent development for how that decision gets scoped on a client build.
- Reads, roughly 6× faster on the project's own single-machine harness.
- Writes, several times slower. Published in the same table, not a footnote.
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 project's own single-machine harness 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 any price: 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.
Why does this page not show the strategy?
Because the strategy is the half that stops working once it is published, and the architecture is the half that transfers. Signal selection, parameters and sizing rules are the edge; a firm that prints them has decided it no longer needs them.
What is worth writing down is the part that survives being copied: what must be true before an autonomous system is allowed to act, how a change earns its way into production, and how you reconstruct a decision afterwards.
Those apply to a payments flow or a clinical workflow as directly as to an order book.
What was Provingmark's role in Neleus?
Anupam Shah co-founded Neleus and ran its capital, regulatory, business development and investor side.
How much does it cost?
A fixed fee against written scope, agreed before work starts and billed at milestones as the work lands.
Who owns the code and the IP?
You do, outright. IP assignment is signed before repository access, by everyone who touches the code, and it covers AI-assisted output. Handover includes the runbook and the rollback path. Nothing depends on a licence we control.
Who sees my code?
Nobody before an NDA. Access is read-only until scope is signed, and you can revoke it at any time. The AI tools used on your code, and what each one retains, are listed on the governance page.
Neleus answered two questions 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. Those are the questions that decide whether an agent can be pointed at a real system.
They shape how we scope an AI agent development engagement.