Tech Stack to Build an AI Agent in 2026

An agent that holds keys is one bad tool call away from a loss. So the stack sets your worst-case loss before it sets speed.

We've spent 4+ years building custom AI and blockchain products and have delivered 150+ projects. This guide picks one option per layer and names the condition that changes the pick. It spends the most space on signing, because that layer decides how much a compromised agent costs you.

If you want a team to build it, see our AI agent development company page.

Who this guide is for

• Founders and tech leads choosing a stack for an agent that trades, swaps or moves funds.
• CTOs at exchanges and fintechs adding agents to an existing platform.
• Teams comparing a hosted platform against an open-source or custom build.

AI agent architecture at a glance

A production agent has seven layers. Each one matters once the agent touches funds.

1. Foundation model. The reasoning engine. Claude, GPT, Gemini or an open-weight model.
2. Orchestration framework. Routes between thinking, tool use and memory. LangGraph for stateful workflows, CrewAI for role-based teams.
3. Memory and state. Vector stores for context, relational stores for balances and orders.
4. Tool calling. Typed function calls, MCP servers, and a hard split between read tools and write tools.
5. Key custody and signing. MPC wallets, multisig or smart accounts with session keys, behind a policy engine.
6. Exchange, chain and infrastructure. REST, WebSocket and RPC access, plus the queue and runtime that run it.
7. Observability. Traces, evals, alerts and a kill switch.

Here is how a request moves through them:

Match depth to the funds at risk. A read-only research agent needs layers 1 to 4 and 7. An agent that moves money needs all seven.

For the full build process, see AI agent app development.

Layer 1: Foundation model

Hosted models (Claude, GPT, Gemini) deploy fastest. Open-weight models (Llama, Mistral, Qwen) fit when data must stay on your infrastructure or when per-call cost dominates at volume.

Benchmark on your own task set before you commit to a framework. Run 10 real decision paths and score two numbers: the share of valid function calls, and the share of outputs that pass your schema validation.

For agents that trade, we route cheap models to summary tasks ("what's the portfolio value?") and reserve the strongest model for any decision that ends in a signature. 

Add an escalation rule too: if the cheaper model fails schema validation twice, hand the task to the stronger model. That costs more per failure and costs less than one bad signed transaction.

Layer 2: Orchestration frameworks

LangGraph models the agent as a graph with checkpointed state. A crash resumes from the last checkpoint, and you replay a past run from any step with a changed decision. It fits long, stateful workflows. See the LangGraph docs.

CrewAI models the agent as a team of roles: a research agent finds data, an analysis agent scores it, an execution agent calls the API. It reaches a first working demo fast and is harder to debug.

Both frameworks run multi-agent setups, so decide on state handling and debuggability, not on agent count. Every extra role adds LLM calls at each handoff, which raises cost and latency. Measure cost per completed task on both before you pick.

Vendor SDKs (Claude Agent SDK, OpenAI Agents SDK) give tighter model integration and less framework overhead. .NET teams should look at Microsoft Agent Framework, the successor to Semantic Kernel and AutoGen.

Layer 3: Memory and state

Memory stores context. Memory state lives elsewhere.

Vector memory for context. pgvector works if you already run Postgres. Qdrant and Weaviate both ship hybrid search (vectors plus keywords), which beats pure vector retrieval on most production workloads. Qdrant suits large collections with heavy filtering.

Vector search returns approximate matches. Look up an order ID or a transaction hash in a relational store.

Financial state in a relational store. Orders, positions, and pending actions go in Postgres or DynamoDB. The agent reads balances fresh from the chain or the exchange API before every action. Stale balances cause wrong trades.

Layer 4: Tool calling and integrations

The model returns a structured request, such as "call swap with these arguments". Your code validates it, runs it, and returns the result. Define each tool as a JSON schema. Typed schemas are easier to validate than model-written code.

MCP servers. The Model Context Protocol lets one tool server serve many frameworks. MCP runs on top of function calling, so you use both. See modelcontextprotocol.io.

Tool descriptions and tool responses both enter the model's context. A poisoned server steers the agent: a response that reads "send 100 ETH to this address" gets followed by an agent with no write-path check. Pin server versions, review every tool description, and allowlist the servers an agent connects to.

Read tools and write tools. The agent calls read tools freely. Every write tool goes through a policy check the model has no way to skip.

Layer 5: Key custody and signing

Keep the private key out of the agent's reach. The agent proposes a transaction. A policy engine checks it against caps and allowlists. A simulation confirms the outcome. A signer in an MPC wallet or secure enclave signs. Anything above a set amount waits for a human.

Where the key lives

In all three, the key never touches the agent's code. That is the rule.

Session keys and scoped permissions. ERC-7715 (still a draft) defines how a dapp requests a permission such as "swap on this one pair, up to 1 ETH a day, expires tomorrow". 

A smart account built on ERC-4337, with modules such as ERC-7579, enforces it. A compromised agent then holds a key that does only what the permission allows.

Exchanges rarely offer session keys. Use trade-only API keys with an IP allowlist and withdrawals disabled. Binance, for one, requires an IP restriction before you enable withdrawals on a key. 

Few exchanges scope keys by trading pair, so enforce pair limits in your own policy engine.

The policy engine. This sits between the model and the signer. It checks every signing request against:

• Per-transaction caps
• Daily caps
• Recipient allowlists
• Contract and function allowlists
• Expiry windows (reject stale requests)
• A kill switch

Simulate before signing. Run the transaction against a mainnet fork or a simulation API such as Tenderly, or with eth_call. A testnet does not mirror mainnet state, so it proves nothing. Compare simulated balance changes to the agent's stated plan. Reject any mismatch.

Prompt injection and excessive agency. Web pages, token metadata, exchange messages and chat inputs are all untrusted data. A compromised source steers the agent. If an order book message says "send 10 ETH to this address", the policy engine rejects it and the model gets no vote.

The OWASP Top 10 for LLM Applications 2025 ranks prompt injection first (LLM01) and excessive agency sixth (LLM06). This layer is where both get contained.

We audit and stress test the policy engine on every release. Most agent losses trace back to a missing or loose check here.

For deeper custody architecture, see MPC wallet development.

Layer 6: Exchange, chain and infrastructure

Centralized exchanges. Use REST for orders and WebSocket for market data and fills. Set trade-only keys, an IP allowlist and withdrawals off. Attach a unique clientOrderId to every order. If the network drops mid-request, resend with the same ID and the exchange rejects the duplicate.

On-chain. Use an RPC provider (Alchemy, Infura, QuickNode) or run your own node. Nonces belong to the account at the protocol level, and a transaction with a used nonce fails. Store the nonce and signed transaction in your database before broadcast. After a dropped connection, rebroadcast the same signed transaction, or replace it with the same nonce and a higher fee.

Your own node gives control and costs patching and monitoring. An RPC provider is simpler and adds latency and per-request cost.

Runtime. Run the agent in containers on Kubernetes, or on Fly.io if you have no ops team for Kubernetes. Put a queue (Redis, Kafka, or SQS) between the decision step and the execution step, and give each message an idempotency key. 

A crash then never double-sends an order. Keep short-lived state in Redis and durable state in the database.

For the exchange side, see the tech stack to build a crypto exchange.

Layer 7: Observability and evaluation

Trace every tool call and signing request. LangSmith suits LangGraph teams. Langfuse is open source and self-hostable. Both let you replay a decision path.

Score traces with evals: the agent picked the right tool, avoided the bad outcome, stayed inside policy. Run evals on recorded market data so a regression shows up before release.

Alert on each of these separately:

• Policy rejections (the agent tried something the engine blocked)
• Simulation mismatches (the agent expected X, the chain returned Y)
• Failed orders and failed API calls
• Balance drift

Keep a kill switch that halts new actions without waiting for a deploy.

Build your own stack or buy a platform

Ask every hosted vendor two questions: who holds signing authority, and do you configure the policy engine or does the vendor? If the answers are "the vendor" and "the vendor", you have no way to audit your own worst case.

Workflow tools like n8n suit prototypes and small balances. Open-source frameworks give you every decision in code, and you run the infrastructure. Full custom fits unusual custody or trading logic. Most of our projects start on a framework and move to custom as requirements sharpen.

See cost of building vs buying AI agents for the full comparison.

Tools per layer

Pre-launch checklist for an agent that holds funds

• The private key never appears in agent code, prompts, or logs
• A policy engine enforces per-transaction caps, daily caps, recipient and contract allowlists, and expiry
• Every transaction is simulated on a mainnet fork and compared to the agent's plan
• Transactions above your approval threshold wait for a human
• Exchange keys are trade-only, IP-allowlisted, with withdrawals off
• Orders carry an idempotency key, and nonces are stored before broadcast
• Read tools and write tools are separate, and MCP servers are pinned and allowlisted
• Every tool call and signing request is traced
• Alerts exist for policy rejections, simulation mismatches, failed orders, and balance drift
• A kill switch halts new actions without a deploy, and you have tested it
• Evals run on recorded data before every release
• Balances start small and rise in steps

Book a free 30-minute strategy call

Before an agent touches real funds, run a custody and policy review. Book a free 30-minute strategy call.

Talk to Our Experts