Steve Agent: Putting the OOBE Stack to Work at ClawPump’s AnsemHack
Steve agent is OOBE’s autonomous perp trader on Solana, built for AnsemHack. Powered by SAP and SAP MCP, it combines market data, risk controls, trade simulation, execution and memory in one live agent workflow.
When we joined the ClawPump x pump.fun x Ansem hackathon, we did not want to build another agent that only talks about markets or generates trading signals.
We wanted to put the infrastructure we have been building at OOBE into a real environment, give it capital, connect it to Solana, and see how far an agent could actually operate.
That became Steve, OOBE’s autonomous perp trading agent on Solana.
Steve can take a trading objective, inspect market conditions, analyze the setup, apply risk controls, simulate the action and prepare the transaction for execution. The experience is simple from the outside, but underneath it runs through the broader OOBE stack.
From an idea to an on-chain action
A lot happens between deciding to take a trade and actually executing it safely.
For Steve, the flow looks like this:
Intent → Market data → Analysis → Policy checks → Simulation → Transaction preparation → User-controlled signing → Execution → Journal
Hermes handles the reasoning. SAP MCP connects that reasoning to Solana.
Instead of building every protocol integration directly into Steve, SAP MCP exposes infrastructure and protocols as tools the agent can discover and use when needed.
This is one of the main ideas behind the OOBE stack. An agent should not need a new custom backend every time it wants to interact with another protocol. It should be able to understand the objective, find the right tool and move through the execution flow.
Steve gives us a practical way to show that.
The OOBE stack underneath Steve
SAP MCP acts as Steve’s execution interface.
Through it, the agent can access the tools needed around a trade, including market data, position management, transaction construction, simulation and perp execution.
The wider OOBE runtime then adds the controls around those actions.
Before a trade reaches execution, policies can check things such as leverage, position size and other risk conditions. Transactions can be prepared and simulated before they are signed, while custody remains under user control.
That allows Steve to operate autonomously without turning the wallet into an unrestricted black box.
The same infrastructure also gives Steve memory and execution journaling, so trades do not exist as isolated prompts. Previous actions, results and relevant context can remain available as the agent continues operating.
Over time, Steve builds an actual execution history.
Where SAP fits
SAP is the broader on-chain coordination layer of OOBE Protocol.
It provides capabilities around agent identity, coordination and verifiable activity that can be used when they add something meaningful to Steve’s lifecycle.
We are not adding SAP components simply so we can say the entire stack is involved. Steve should remain easy to understand: it is a perp trading agent first.
The important part is that the infrastructure underneath can grow with it.
SAP MCP gives Steve access to the tools. The OOBE runtime manages the execution flow and controls around them. SAP can add deeper on-chain capabilities as the agent evolves.
Together, they turn Steve from a trading prompt into an agent that can actually operate.
Why Steve matters for OOBE
Until now, much of our work has been infrastructure: SAP, SAP MCP, runtime systems and integrations across Solana.
Steve puts those pieces under real pressure.
Market data has to be useful. Risk controls have to work at the right moment. Simulations need to catch bad transactions. Different tools need to work together, and the agent needs to preserve enough context to make the next decision better informed.
That makes every Steve trade useful beyond its PnL.
It gives us another real execution path through the OOBE stack and another chance to see where the infrastructure can improve.
This is what makes Steve interesting to us beyond the hackathon. It is a focused product on the surface, but also a live test of the agent infrastructure we have spent the last year building.
How we are approaching AnsemHack
Our plan is not complicated.
We want Steve trading early, building an on-chain history and improving from what happens in the market.
Instead of optimizing for one lucky high-leverage trade, we want to show that an agent can repeatedly move from analysis to controlled execution while managing risk along the way.
The hackathon gives us the right environment to prove that with real activity rather than a demo.
Steve is the trader people interact with. Underneath, SAP MCP, the OOBE runtime and the broader SAP infrastructure are doing the work that makes that experience possible.
For us, that is the real experiment: can the stack we built for autonomous agents hold up when an agent is actually using it every day?
AnsemHack is where we find out.
About the Steve token
Tokenization is part of the AnsemHack participation requirements, which is why Steve launched with its own token.
The token is not positioned as an investment product, and OOBE does not recommend buying or trading it.
We are also planning an airdrop for $OOBE holders to bring part of the $STEVE experiment back to the existing OOBE community. More details will be shared once the structure is finalized.
Website is live: https://steve.oobeprotocol.ai/
Written by Solking