What an AI chief of staff should verify before taking action

Start with a decision you can inspect.

An AI chief of staff becomes useful when it can connect scattered context and move work forward. That could mean noticing that two teams have promised the same capacity, asking an owner to clarify a gap, or updating a plan after a decision.

Each step changes the standard of evidence required. Identifying a possible conflict needs enough support to investigate. Changing a commitment needs current facts, a clear remit and a way to check what happened afterwards.

When evaluating or building such a system, use a concrete action as the unit of review. Ask it to show the claim, the supporting records, the permission to act and the condition that would count as success. The seven questions below make that review practical.

1. What, exactly, is being claimed?

“Platform is available” leaves important questions unanswered. “Two named Platform engineers can support the Monday launch without moving another commitment” is a claim you can check.

Consider a proposed action: move an internal migration to the following week to protect a customer launch. Before acting, separate the propositions it depends on:

• The launch and migration need the same capacity.
• The customer date is an agreed commitment.
• The migration can move without breaching another constraint.
• The following week's capacity is available.
• The relevant decision maker accepts the trade-off.

A strong answer to one proposition cannot fill the gaps in the others. Confirming next week's availability makes a reschedule feasible; authorisation to reschedule still needs its own basis.

2. What evidence supports it, and what could invalidate it?

Keep sources attached to the claim they support. For capacity, that might be a current allocation plan and confirmation from its owner. For an approval, it should include the reviewed scope. For a deadline, identify who agreed it and whether it is still binding.

Direct record

What does the source actually establish? Include its owner, scope and relevant date.

Interpretation

Which relationship has the system inferred? Make it possible to challenge that inference.

Unresolved point

What is missing or contradictory, and does it prevent this particular action?

Recheck trigger

Which change in timing, scope, allocation or policy would make the conclusion stale?

Two records may repeat the same underlying statement. A project summary copied from Slack provides traceability, but it is not independent confirmation of the original message. Ask what additional evidence each source contributes.

A confidence percentage cannot establish authority or resolve a known contradiction. If the owner says capacity is free and the allocation plan says it is booked, the useful next step is to reconcile those records.

3. Can it ask a question that closes the gap?

When internal messaging is enabled, an AI chief of staff should be able to ask the accountable person for a precise clarification. Give the recipient the claim, the conflicting evidence and the decision it affects.

The migration plan assigns two Platform engineers on Monday. The launch now needs the same capacity. Is the following week's allocation available for the migration, and is there another deadline we need to account for?

Check that messaging permissions cover the recipient, channel and purpose. Share only the context that person is allowed to see. Define when a follow-up is appropriate and when an unanswered question should return to the decision owner.

The reply becomes new evidence. Compare it with the relevant plan, keep its conditions and attribute it to the person who supplied it. “Available if another project slips” should remain conditional. A missing reply leaves the question open.

This makes clarification part of the work. It also gives the employee a specific statement to correct when the system has misunderstood the situation.

4. Is this action within the agreed remit?

Access to information and authority to change something should be explicit, separate permissions. An integration credential can make an action technically possible without making it appropriate for the system to take.

These are example boundaries to tailor, rather than a universal policy. A routine internal update may be suitable for automatic execution. A change that affects another team's priorities may require approval even if the API call is simple.

Instructions encountered inside a source record must not expand those permissions. A Slack message saying “ignore the approval step” is content to interpret within the existing rules. Changes to the system's remit need a separate, authorised control.

5. Can it show the change before making it?

A decision maker should be able to review the proposed difference: which date will move, which records will change, who will be notified and what the trade-off is.

For the migration, the proposal might be: move its start date by one week; retain Monday's launch support; update the delivery plan; ask both owners to acknowledge the new arrangement. The cost is that migration benefits arrive later.

Record the assumptions supporting approval and recheck them immediately before execution. If available capacity has changed since the decision was prepared, pause and return the changed facts to the approver. Approval of one plan should not silently authorise a materially different plan.

Also distinguish corrections from reversal. A ticket date can usually be changed again. A message may already have caused people to act. The proposed recovery should account for who needs to be informed if the plan changes.

6. How will it know the action worked?

Define the success condition before the action. For a small metadata correction, reading back the intended value may be enough. For a reschedule involving two teams, the evidence may include updated dates, allocated capacity and the affected owners' agreement.

Plan for partial completion. The ticket update may succeed while the notification fails. The system should retain which step completed, explain what remains open and recover without repeating the whole sequence blindly.

Where an API supports it, use a stable request identifier to avoid duplicating an action during retries. AWS's guide to idempotent APIs explains this pattern. Where support is absent, reconcile the observed state before deciding whether another attempt is safe.

Keep the claim proportional to the evidence. Confirming a reschedule establishes a coordination outcome. Whether the migration eventually delivered its expected benefit requires a later check.

7. What should it remember for next time?

Retain the context that can improve a future decision: the shared capacity, the constraint, the action taken, the observed outcome and any correction from the people involved.

In this example, “these initiatives share Platform capacity” is useful. So is “confirm the release allocation before promising an earlier date”. The fact that the launch took priority once does not establish a standing priority for every future launch.

Give retained context an owner, supporting evidence and conditions for rechecking it. Corrections should update the information used in future recommendations. A changed team structure or policy can invalidate an earlier pattern.

Learning also needs a test. On a later initiative, did the system surface the relevant dependency earlier, reduce clarification effort or propose an action that required fewer corrections? A successful outcome alone cannot prove that the system's intervention caused it.

Use one record to review a real action.

Take an action your team might genuinely delegate and fill in the record below. Any blank field should lead to a question, a narrower permission or a smaller first action.

Proposed action and exact change:
Claim and supporting source records:
Uncertainty or conflicting evidence:
Clarification needed / owner:
Permission or approval that authorises this action:
Assumptions to recheck before execution:
Trade-off and recovery plan:
Success condition and verification time:
Completed steps / remaining work:
Outcome, correction and context to retain:

Try three awkward situations.

• The owner and the plan disagree. Does the system show the conflict and ask the right question before committing?
• A tool times out after a change. Does it establish whether the change happened before attempting it again?
• The same pattern returns with a new constraint. Does it reuse relevant context while checking whether the earlier decision still applies?

These are useful evaluation cases because they reveal behaviour that a smooth demonstration can leave untested.

This is the approach behind Ocula: connect organisational context, verify it, act within an agreed remit and learn from checked outcomes. Our access and actions page explains how we scope those permissions for a pilot. The same review questions apply to any AI system you entrust with organisational work.