A personal wallet is like a house key: one person, one door, one big responsibility. An organization doesn’t live in a house—it lives in a factory. There are rooms, shifts, badges, supervisors, safety rules, and a fire alarm nobody wants to pull but everyone wants to trust. If autonomous agents are going to touch company money, the wallet can’t stay a house key. It has to become a badge system.
The old EOA model was never built for that factory. One private key can’t express “marketing can spend $5k/day, procurement can add vendors but can’t pay them, payroll can pay only whitelisted employees, and an AI agent can do small routine settlements but must wake a human for anything weird.” You can bolt on spreadsheets and approvals in Web2, but on-chain, the key still holds the gun.
Account abstraction is the first big step away from “one key rules all.” ERC-4337 changes the mental model from “a transaction signed by a person” to “an operation executed by a programmable account,” using UserOperations routed through an EntryPoint and bundled for inclusion. That one shift is why “organization + agents” becomes realistic: the account itself can enforce rules, not just the humans around it.
Once the account is programmable, the wallet stops being a container and starts being a policy engine. ERC-4337 explicitly enables custom signature logic, batching, and flexible fee payment via Paymasters. In a company context, “custom signature logic” is where roles and departments live. It’s how you turn “approval matrices” into code instead of Slack messages.
But organizations don’t want one monolithic wallet contract that tries to do everything. They want composability—swap a policy without rebuilding the entire treasury. That’s why modular smart accounts are such a big deal for the next wallet generation. ERC-6900 standardizes a modular smart contract account where validation logic, execution logic, and hooks can live as external modules. It’s basically the idea of “plugins for authority.” You can attach a spending-limit policy, then later attach an additional reviewer policy, then later attach a session-key policy for agents—without rewriting the core account.
ERC-7579 takes a similar modular direction (with its own design choices), and the ecosystem is already building modules like hooks, validators, and recovery patterns around it. The important part isn’t which modular standard “wins.” The important part is the direction: wallets becoming software platforms where “who can do what” is a set of installable parts, not a single brittle contract.
Now zoom into what an organization wallet actually needs, beyond the buzzwords.
At the top, you need a root treasury that behaves like a constitution. It should be hard to change, slow to override, and extremely boring. That root account likely stays multi-sig or threshold-based for anything structural: changing owners, installing modules, altering global budgets. This is where you keep the “break glass” controls.
Under that, you want departments to feel like sub-ledgers without forcing a dozen separate wallets. The clean pattern is “one treasury account, many budget envelopes.” Budget envelopes are not new—Safe, for example, supports modules like spending limits that allow controlled allowances to beneficiary addresses without collecting the full signature threshold every time. Translate that to organizations: each department (or each automation role) gets an allowance policy tied to permitted tokens, periodic limits, and allowed destinations.
Then come agents. Agents shouldn’t hold the factory master key. They should operate like forklifts: powerful inside their lane, useless outside it. That’s where session keys and scoped permissions become the practical center of “agents in finance.” ERC-6900’s ecosystem even explicitly references session key plugins as a standard module category. The concept is simple: the smart account grants a short-lived key the ability to perform a narrow set of actions (pay these invoices, call these contracts, spend up to X, expire at Y). When the shift ends, the badge expires.
This is the wallet architecture that starts to look like an org chart: root owners at the top, department policies in the middle, and many small session “hands” at the bottom that do work but can’t rewrite the rules of work.
One subtle point: teams don’t just need permissioning—they need compositional permissioning. Real company workflows aren’t “either allowed or not.” They’re “allowed if… and only if… and also log it… and require two approvals above a threshold.” That’s exactly the kind of thing modular accounts and hooks are designed for. A hook can enforce pre-conditions (like allowlists, time windows, risk checks) and post-conditions (like logging, receipt generation, or automatic reconciliation tags).
The other subtle point is that organizations don’t live on a single chain forever. So the wallet needs portability and upgrade paths that don’t strand policy history. Standards like ERC-6900 aim to reduce fragmentation between account implementations so modules can be reused across accounts rather than locked into one vendor’s design. For enterprises, that’s not ideology. That’s procurement: they don’t want to redesign controls every time tooling changes.
This is also why EIP-7702 is so important as “the bridge between old wallets and new wallets.” It lets an EOA set code via delegation, explicitly calling out features like batching, sponsorship, and privilege de-escalation—meaning even legacy accounts can adopt “smart account behaviors” without fully migrating into a new address identity. For organizations, privilege de-escalation is the heart of agent safety: the agent gets a weaker key with narrower rights, not the crown jewels.
Now tie this back to Kite, because Kite’s whole pitch is that agents are first-class economic actors, not an afterthought.
Kite’s whitepaper describes a three-layer identity architecture—user (root authority), agent (delegated authority), session (ephemeral authority)—implemented via hierarchical derivation, plus a unified smart contract account model where multiple verified agents operate through session keys under cryptographically enforced constraints. That maps almost perfectly onto the “factory badge system” model: the company (user layer) delegates to departments or agent roles (agent layer), which spawn short-lived working permissions (session layer).
What makes this especially enterprise-shaped is Kite’s emphasis on programmable constraints and compliance-friendly audit trails. The whitepaper frames this as cryptographically enforced spending rules plus immutable logs with selective disclosure, so organizations can delegate authority while still proving compliance. In plain language: you can let the bots operate, and still answer the auditor’s favorite question—“show me why this was allowed.”
The dream version of this architecture looks like a “wallet workspace” where an organization can define roles the way it defines job descriptions.
A procurement role that can onboard approved vendors but can’t pay them.
A finance-ops role that can pay approved vendors but can’t add new ones.
A reimbursement role that can settle small employee expenses with strict caps.
An AI scheduling agent that can spend small amounts for bookings under clear categories.
A trading or treasury agent that can rebalance within risk bands, but must ask for human approval outside volatility triggers.
Kite’s own examples in the whitepaper explicitly talk about per-agent limits and velocity controls enforced by session keys and programmable rules. That’s not marketing fluff; it’s the exact vocabulary enterprises already use, just translated into on-chain enforcement.
But building “organizations + agents” wallets has a trap: complexity can become the new attack surface. Modular wallets are powerful, but every module is also code you’re trusting. That’s why the ecosystem is moving toward module registries and security attestations—EIP-7484, for instance, proposes a registry extension so modular accounts can verify module security via registry adapters. If org wallets become plugin ecosystems, then “which plugins are allowed” becomes as important as “who can sign.”
And then there’s the operational risk: someone will try to grief the system with expensive validation or weird edge cases. Standards like ERC-7562 exist specifically to constrain validation behavior in AA systems so bundlers can simulate safely, throttle abusive entities, and prevent denial-of-service patterns. That matters for organizations because the fastest way to lose internal confidence is when finance automation intermittently fails under load or gets jammed by adversarial flows.
So the wallet architecture for “organizations + agents” is heading toward a recognizable shape: smart accounts as the treasury core, modular policies as the org chart, session keys as the daily worker badges, and audit trails as the paper trail you can’t fudge. Kite’s unique angle is making that shape feel native to agent behavior—especially with a session-based model, programmable constraints, and a payments rail designed for high-frequency agent activity.
If this wave lands, the biggest change won’t be that wallets get nicer UIs. The biggest change is that the wallet stops being a “thing you own” and becomes a “system you run”—with teams inside it, agents inside it, and rules that hold even when nobody is watching.
