Sequence is the financial execution layer for AI agents. Your agent can send, split, and route real money across all your bank accounts, cards, apps, and loans with scoped keys, server-side spending limits, and full audit trails. One API call from Claude, Cursor, n8n, or Zapier.
This is the 2nd launch from Sequence. View more
Sequence Agentic
Launched this week
Sequence is the financial execution layer for AI agents.
Unlike read-only tools, your agent uses the Sequence API to send, split, and route real money across all your bank accounts, cards, apps, and loans. Scoped API keys mean agents never hold your credentials, server-side spending limits keep you in control, and full audit trails log every action. The infrastructure is battle-tested in production on regulated rails, moving north of $3B. One-call integration from Claude, n8n, Zapier etc.
Free Options
Launch Team / Built With
Wealthfront
Sequence
The scoped-keys-plus-server-side-limits part is the bit that actually matters here, and it's easy to underrate. I build agent tooling and prompt-level guardrails always leak eventually. Tell an agent 'never move more than $500' and under the wrong instruction chain it will cheerfully try anyway. The only thing that holds is a limit the agent literally can't see or edit. Question for @gilad_uziely: are the limits scoped per-key or per session, and can a compromised agent widen its own scope?
Sequence
@gilad_uziely @dipankar_sarkar limits are scoped per-key, and an agent cannot widen its own scope. limits can both limit source & target account pairs, and apply an amount limit ("don't move more than 100$ at once", or "don't move more than 100$ a month to this account"). We believe agents need deterministic independent guardrails when it comes to your finance.
spending limits and audit trails are the right instinct but the part i'd want to poke at is the failure mode where the agent's reasoning is fine on paper but it moves money based on a hallucinated balance or a bad read of an invoice. is the audit trail just a log after the fact, or is there a human approval step for anything above the scoped limit before it actually executes
Sequence
@omri_ben_shoham1 It really depends on how you choose to scope the key you give your agent ahead of time when you initially create the API key. The options for scoping are really granular, so you can effectively create a key that only allows "teeing up" the transfer/ automation but requires a human to click approve
Thanks Sigal, the per-month-per-account ceiling is the part I care about most, because it's stateful in a way a prompt guardrail can never be, it survives across sessions and restarts. The thing I keep hitting building agents is the mid-plan rejection: when a movement gets denied for hitting a limit, does the agent get back a structured error it can actually reason about and re-plan around, or does the whole run just fail? And are retries idempotent if it resends the same movement?
Sequence
@dipankar_sarkar Money movements are async. When you trigger a money movement, you get a job ID, can track it's progress, including informative errors.
Retries are idempotent given you're using our idempotency token field.
The static limits and audit trail cover the case where the agent misbehaves on its own, but what about prompt injection through the data it reads, like an invoice PDF that contains hidden text telling the agent to route the payment to a different account. Does the anomaly detection catch a transfer that's within the scoped limit but going to a destination it's never used before, or does anything under the limit just go through?
Sequence
@galdayan Great question - this is the right threat model, since limits + audit trail only cover the agent misbehaving on its own, not a poisoned input.
Each API key is scoped to an explicit allowlist: which source accounts it can pull from, which destination accounts it can send to. Every transfer is checked against that allowlist - a payment to an account that isn't on it is rejected outright, regardless of amount. So a hidden "route to account X" buried in an invoice PDF has nowhere to land: X isn't on the key's target list, and being under the limit doesn't help it.
On top of that, money can only ever move between accounts already linked in Sequence - the agent references existing destinations; it can't supply a raw account/routing number at payment time. Prompt injection can't conjure a new payout account into existence.
Please let us know if you have any more thoughts or questions :)
How does scoped key isolation actually work when an agent needs to move funds between two of my accounts that share a login, do you set up separate sessions per task or is it one persistent auth context with per-call limits layered on top?
Sequence
@abanaltmgzpk You have three guardrail systems you can use:
Agent-key scope: in advance, setup multiple keys per-task. Each key contains his set of source and destination accounts, with his amount limitations (which can both be set on the key, or limited by using a sub-account for source, only funding it as much as you want to allow the agent to use). Give each agent a key according to his job-to-be-done. Connect each agent only with the key you want it to have.
Configuration scope: use our rules framework to set up a deterministic configuration. This configuration allows money movement, in a simple "if-else" framework. There you can give statements like "only move money if my checking account balance is above 500$", or "pay for my card debt upto 300$ a month", or "top up the emergency funds sub-account up to 400$". Give your agent only the ability to trigger these rules, so it cannot go crazy.
Putting the spend limits in the key server-side instead of in the prompt is the right call — the scoped-key answer above is the only thing that actually holds when an agent's reasoning goes sideways. The operator edge case I'd want pinned before wiring an agent to live money is retries: if an agent fires a transfer, times out, then retries, is there an idempotency key so it doesn't double-send? And for an in-limit but wrong transfer, is there any reversal/clawback window, or is it final on execution?
Sequence
@hazy0 We have idempotency tokens and recommend using them just for this case.
Reversal process is according to standard banking timing limitations, and can currently be done via our support.