Confirming what an assistant proposes

Where proposals live

Every company has a Proposals page under Approvals & Notices in the left navigation, next to Board. The number beside it is how many proposals are waiting on someone. The page lists what is waiting first and the history - confirmed, declined, expired, superseded and failed - below it. Every member of the workspace can read the list; the decision is on each proposal’s own page.

The assistant gets the same link. When a tool proposes a change, its answer carries a confirmUrl, and a well-behaved assistant hands it to you.

What a proposal shows

• What. The change in plain English - “Issue shares”, “Grant option” - with a one-line description of what that capability does.
• Ownership before and after. For a change that moves shares, a table of every holder it touches: their stake before, their stake after, and the share delta. For other changes, the fields that would change, before and after.
• Preconditions. The checks Tenacap ran when the change was proposed, each marked blocker or warning, with a link to the record it came from. A blocker means the change cannot be applied until it is resolved - the proposal stays open so you can see why. The checks run again the moment you confirm, so once you have resolved the blocker (recorded the board approval, say) confirming applies the change; if it still stands, the confirm is refused and the page shows the fresh report. You can also decline. A warning is for you to weigh.
• Who proposed it. The person whose token was used, and the token’s name - so “Sam via token Claude Code on my laptop” tells you which client asked.
• When it expires. Seven days after it was proposed.

Who can confirm

Each capability has a minimum role - most writes need Editor, governance actions need Admin - and the proposal page names it. A member holding that role in the company’s workspace sees Confirm and Decline; a member below it sees everything else and a note saying who decides. Roles are described in Roles and permissions.

Confirm or decline, with a reason

Both buttons take an optional reason: your own sentence about why, kept with the decision and shown on the proposal afterwards (“matches the board consent of 9/12”, “wrong holder, ask again”). Declining writes nothing. Confirming applies the change as if you had made it on the page yourself, and the proposal shows the result with a link to the change log.

Confirm all

When two or more proposals are waiting that your role lets you decide, the Proposals page shows Confirm all with the count. It confirms them one at a time, oldest first, because a later proposal can depend on an earlier one (a share class before shares issued in it). Each one goes through the same checks as confirming it on its own page, and the run stops at the first one that cannot be applied. The page then lists what was confirmed, which one stopped the run and why, and which were left waiting. Nothing after the stop is applied; open it, sort out what stopped it, and confirm the rest.

Confirming a change to the shares moves the cap table, and on its own page each later proposal would then ask you to look again. Within one Confirm all run it does not: a proposal made against the cap table as it stood when the run began goes ahead after the earlier ones in the same run, its change is worked out again against the table they left, and the change log records that it was confirmed with Confirm all. So a share class and the founder stock issued in it can be confirmed in one go. If anything else changes the cap table during the run (someone else’s edit, an import), or a proposal was made against an older cap table than the one the run began with, the run stops there with “the cap table changed”. Open that proposal, look over the updated change, and confirm it there. Confirm all takes no reason; to record one, confirm on the proposal’s own page.

A few proposals are confirm-only: sending a stockholder consent, e-mailing your stockholders, requesting a signature, marking a board approval approved, marking a filing as done. Confirming one runs that step as you, right away - the button says Confirm and send. If the send fails, the proposal says so and reads as failed, and the assistant can propose it again.

When the cap table moved first

The diff you are shown was computed against the cap table as it was when the change was proposed. If anything on the ledger changed in between - another issuance, a conversion, an import - your confirmation is not applied. Tenacap recomputes the diff against the current table, shows it to you, and asks you to confirm again. Nothing is written until you confirm a diff that is still true; that check runs under the ledger’s own lock.

A proposal that creates a company

When you set up a company from Claude, the first proposal comes before the company exists: create_company for an empty company, or create_company_from_import for one built from an export. It has no Proposals page to sit on, so it has its own page at the link the assistant hands you. That page shows what would be created and the checks that stand, with Confirm and Decline. Only an Admin of the workspace can confirm it, and no e-mail is sent for it, so keep the link. Once it is confirmed, the same link opens the proposal inside the new company, and everything after that (share classes, founders, SAFEs, the pool) arrives as ordinary proposals on the company’s Proposals page.

Expiry and superseded proposals

A proposal nobody decides expires after seven days; the assistant can propose it again. If an assistant repeats the same proposal while the first is still open, it gets the same proposal back. If the cap table has moved in between, the earlier proposal is marked superseded and a fresh one, with a fresh diff, takes its place.

The e-mail

When a change is proposed, the members whose role could confirm it get an e-mail with a link to it. The person whose own assistant made the proposal gets no e-mail: they asked for it, and the assistant hands them the link in the conversation.

One request to an assistant often becomes several proposals. Those arrive as one e-mail. After an e-mail about a proposal from one assistant connection, further proposals from that same connection to the same company in the next 15 minutes are added to the Proposals page without another e-mail. The e-mail says how many changes are waiting and, when there is more than one, links to the Proposals page. A proposal that comes more than 15 minutes after the last e-mail sends a new one.

Turn the e-mail off under Settings → Notifications (“An assistant proposed a change”). A company’s proposal mail is also capped at twenty an hour, so a looping assistant cannot flood an inbox; the proposals themselves are still recorded and listed.

What the change log records

A change applied from a proposal writes the same change-log entry the page would, with the person who confirmed it as the actor - and, sealed inside the same tamper-evident record, which token proposed it, which proposal it applied and who confirmed it. The change log says so under the actor (“confirmed an assistant’s proposal via token …”, linking to the proposal), and the CSV download carries the proposal id, the token and the proposer in its last three columns, so a reviewer can tell an assistant-originated write from a hand-made one at a glance. Read more in Change log and audit trail and Connect your AI assistant.