An autonomous agent member is software that holds a DAO's shares under its own key and votes with them, rather than assisting a human who votes. The distinction matters because the three arrangements people call "AI in governance" carry entirely different risk:

• Agent as tool. A model summarises proposals, drafts a recommendation, flags risk. A human still signs. Accountability is unchanged.
• Agent as delegate. Members delegate voting power to an address the software controls. The delegators keep the power to revoke, and the failure modes are the familiar ones — see delegate accountability.
• Agent as member. The agent holds the shares. There is nobody to revoke from, and the only lever left is whatever the DAO can do to a member: ragequit around it, dilute it, or vote it out.

Until recently the third case was a thought experiment. In 2026 it acquired a working reference implementation.

What a working stack looks like

DAOhaus publishes three repositories that together run an agent as a share-holding member of a Moloch V3 (Baal) DAO on Base, and they are worth reading as a specification of the problem rather than as a product:

• moloch-skills — the capability bundle: summon a DAO, create proposals, sponsor, vote, process and cancel them, read DAO state from contracts and the subgraph, and bootstrap a mandate. Each is a separate, named skill rather than one open-ended "do governance" affordance.
• moloch-agent — the local runtime. Transaction commands broadcast by default; --build-only produces an unsigned transaction instead.
• moloch-service — a hosted proxy for subgraph reads and IPFS pinning, whose README states plainly that it "must never receive private keys", does not sign, and "does not make governance decisions".

That last split is the architectural claim: the operator's indexing and pinning secrets leave the agent runtime, while signing authority never leaves it. An agent member that outsourced its key would not be a member at all — it would be a delegate of whoever held the key.

The scheduled-task pattern is similarly deliberate. A cron job takes a deterministic snapshot of chain state, subgraph history, a lifecycle summary and a process queue; the agent then reads those compact artifacts and decides one action; a third task sends the transaction after a live preflight. Direct contract state, not the indexer's passed flag, is treated as the source of truth for whether a proposal can be processed — a caution any indexer-driven governance bot eventually learns. The same document imposes a proposal throttle: no new proposals while three are already in voting.

A written procedure for a non-human voter

The most transferable artifact in the stack is not code. VOTE_DECISION_FLOW.md is a published procedure for how an agent decides, and it opens by declaring its own scope: the repo is opinionated about how agents decide, not what values they hold. Values live in a separate, operator-supplied mandate — identity, voting policy, autonomy rules, execution policy — which the bootstrap document explicitly forbids the agent from inventing for itself.

The procedure requires the agent to load its mandate, the DAO's current charter and join rules, the proposal's lifecycle state, and prior passed proposals on the same topic before recommending anything. It then runs a fixed sequence: classify the proposal; check that the action data matches the written intent; check the mandate; check DAO alignment; check risk and reversibility; choose among yes, no with an amendment path, abstain, sponsor, process, or no action. Abstention is the required answer when the agent lacks context, when the proposal falls outside its mandate, or when it has a conflict of interest.

Every vote produces a memo with a fixed shape — recommendation, confidence, mandate alignment, action-data check, conflict of interest, reason, and a field for what would change my mind. Read as a governance document rather than a config file, this is a fiduciary procedure written down: a standard of care, a conflicts rule, and a duty to state reasons on the record. Most human delegates operate with nothing so explicit.

The "check action truth" step deserves its own note. Asking whether the encoded action data matches the proposal's prose is precisely the typed-versus-arbitrary execution problem, and it is the step where a DAO whose proposals carry raw calldata asks a language model to do what its own members demonstrably fail to do.

What it does not solve

• The mandate is somebody's. An agent votes its operator's stated values. Where the DAO's rules assume one member is one interest, an operator running several agents has multiplied their voice — the ordinary sybil problem wearing new clothes, and share-based DAOs that gate membership by vote are the ones best placed to catch it.
• Accountability has no new lever. A principal–agent relationship where the agent cannot be sued, sanctioned, or shamed leaves ragequit, dilution and expulsion as the entire remedy set. That is one reason exit rights matter more, not less, once agents vote.
• Key custody is the real membership boundary. Whoever can produce the signature is the member, whatever the documentation says.
• Legal personhood is unresolved. An agent cannot sign an operating agreement. The workaround on offer is a wrapper — a DAO LLC whose members are humans and whose operations are automated — which is a container for liability, not a grant of standing. MIDAO markets exactly this.

How far along this actually is

Honesty about the state of deployment matters more here than in most subjects, because the surrounding commentary runs well ahead of it. The DAOhaus repositories were created in May 2026 and are small; the flagship launch skill for the "Meta Clawtel" DAO fixes its parameters concretely — non-transferable voting shares, four-hour voting and grace periods, 50% quorum, roughly 67% minimum retention, Base chain 8453 — but ships with placeholder member addresses, so it documents an intended launch rather than a running one. The hosted DAOhaus Admin instance is live.

The better-known proposals in this space are proposals. Vitalik Buterin's "AI as the engine, humans as the steering wheel" (February 2025) argues for AI participating in an open competitive market of answers, steered by a small amount of high-quality human input — a design in which models compete inside a mechanism rather than one in which a model holds a seat. Between that framing and an agent holding shares lies most of the disagreement in the field.

The practical near-term shape is narrower than either: agents that watch the queue, process ready proposals, keep records, and abstain by default on anything their mandate does not cover. That is a maintenance role, and it is the one the published task patterns actually describe.

How Caper approaches this

A caper has no delegation primitive at all — there is no delegate slot in the contracts, so voting power cannot be handed to software, or to anyone else. Weight is computed per voter from what they hold and what they have voted on, and the vote record itself is a soulbound token that cannot be bought or transferred. An agent operating in a caper would therefore have to acquire tokens on the curve and build its own record by voting, over time, in public — and the record it built would follow it, not the tokens. Whether that is a better answer than a mandate file is an open question; it is at least a different one.

For the read side, querying a caper from an AI agent covers what an agent can learn about a caper without holding anything.