Problem
Giving an AI agent the ability to place real trades is a fundamentally different problem from giving it the ability to answer questions about the market. The product let users acquire and configure AI agents, voice- and chat-driven, for portfolio management. But the moment an agent can call a trade-execution tool, the real question stops being "is the agent smart enough" and becomes "what happens the first time it's wrong, or misreads an instruction it shouldn't have acted on." A capable model with unrestricted account access is a liability, not a feature, no matter how good its reasoning usually is.
The platform needed a way for a non-technical user to grant an agent real capabilities, things like trade execution, DeFi swaps, and prediction-market bets, while keeping enforceable, auditable limits on what any given agent instance could actually do. Those limits had to hold regardless of how sound the agent's reasoning turned out to be on a particular call.
Architecture
The agent system separates what an agent can reason about from what it's allowed to do, across four concerns.
Marketplace and tools. Users acquire agents and toggle individual capabilities per agent instance: trade execution, chart analysis, fundamental analysis, DeFi swap preparation, prediction-market search. A tool being enabled only determines what the agent is logically capable of, not what it actually has access to.
Connections. Brokers, prediction markets, and Web3 wallets get linked at the user's profile level, then explicitly granted or withheld per agent. A user might have five broker accounts connected overall but restrict a given agent to exactly one of them.
Policy engine. This is where the actual guardrails live: max order size, max daily loss, allowed asset classes, allowed symbols, trading hours, and a human-in-the-loop threshold above which trades need explicit confirmation no matter what the agent decided.
Risk guard. A synchronous check that every trade-execution call passes through before it reaches a broker. Is the agent active? Is the symbol allowed? Does size times price exceed the order cap? Has the daily loss limit already been hit? Any failure blocks the trade and logs a policy-violation event. None of this is advisory.
Underneath all of it, a unified trading overlay normalizes stop-loss, take-profit, and trailing-stop logic across brokers so only plain entry and exit instructions ever reach a broker adapter. A vector-backed retrieval pipeline gives agents context from documents users upload themselves.
Implementation
The policy engine and the tool-toggle system are deliberately independent axes rather than one combined permission. A tool being enabled says the agent can call trade execution. A connection being granted says it has a broker to call it against. A policy says what happens when it tries. All three have to be true at the same time for a trade to reach a broker, so removing any single one is enough to stop it. That's what makes "can this agent hurt the user" a matter of checking three independent, auditable tables instead of untangling one combined permission blob.
Every agent action, whether that's reasoning, a tool call, an error, or a blocked attempt, gets written to an event log as a distinct thought, action, or policy-violation record. That log isn't just observability. It's how a user can reconstruct exactly why an agent did or didn't do something after the fact, which matters enormously the first time an agent's behavior needs explaining to someone.
External AI clients, not just the platform's own voice interface, can drive an agent through a scoped, API-key-authenticated endpoint. That connection doesn't get its own permission model though. It resolves to a specific agent and inherits that agent's exact policy and risk-guard checks. An external client can't do anything through that channel that the agent couldn't already do through the platform's own UI.
Challenges
The hardest design constraint was making sure there was no path, whether voice, chat, an external client, or some future integration nobody's built yet, that could reach a broker without passing through the same risk guard. That ruled out putting any risk logic inside the voice agent or the external-connection server themselves. Both had to stay thin callers of the same underlying trade-execution path, with policy enforcement living in exactly one place instead of being reimplemented, and potentially drifting, at every new entry point.
Pause states needed to distinguish why an agent actually stopped. A user pausing an agent and an agent hitting its daily loss limit both look like "the agent isn't trading right now" on the surface, but only one of them should force the user to review and adjust limits before resuming. Collapsing the two into a single paused state would have let a risk-triggered pause quietly resume itself the next time the user casually toggled the agent back on.
Results
Users can hand an agent real trading capability across multiple broker types, DeFi, and prediction markets without that capability being all-or-nothing. Every agent instance operates inside limits the user set explicitly, enforced identically no matter which interface initiated the action. The layered design means a single, auditable risk guard is the only place a trade can be blocked or allowed, which keeps "why did or didn't the agent do that" answerable straight from the event log instead of requiring a debugging session across half a dozen services.