Feature: Verify business task outcomes before marking them complete

Problem / motivation

While exploring how Don't Be Michael manages its agents, I noticed that the system already has mechanisms for tracking agent activity, handling approvals, managing costs, and detecting failures.

But one question kept coming to mind: how does a business owner know that a task was actually completed correctly, rather than just knowing that the agent finished running?

For example, imagine a small business owner asking Michael:

"Check our overdue invoices and send payment reminders to customers who haven't paid yet."

The Finance agent processes the request and reports that the task is complete.

But what if:

• Two customers accidentally received duplicate reminders?
• A customer who already paid received a reminder because the data was outdated?
• Three overdue invoices were silently skipped?
• The agent reported success even though one of the underlying operations failed?

The agent might have finished its execution without achieving the expected business outcome.

For a small business owner who isn't technical, checking logs or manually verifying every result defeats the purpose of having an autonomous AI office.

There is a difference between an agent completing its execution and a business task being completed correctly.

Proposed solution — Outcome Verification

I'd suggest adding a lightweight Outcome Verification layer that checks whether an agent's work produced the expected result before Michael reports it as verified.

Rather than relying only on the agent's completion message, Michael would compare the expected outcome against available evidence from the tools and business systems involved.

A first version could work like this:

1. Define expected outcomes: When Michael delegates a task, capture a few measurable success criteria where possible.
2. Execute normally: The assigned agent performs its work using the existing permissions, integrations, and approval mechanisms.
3. Collect evidence: Capture relevant tool responses, operation results, and available business records.
4. Verify independently: Run read-only checks comparing the expected outcomes with the actual results, without trusting the agent's own completion summary as proof.
5. Report the result: Michael presents a clear verification status, supported by evidence.

The owner would see one of three possible outcomes:

• Verified: Available evidence confirms that the expected actions were completed correctly.
• Partially Completed: Some expected outcomes were achieved, but others failed or remain incomplete.
• Needs Review: The available evidence is insufficient, conflicting, or indicates a possible problem.

Verification should be independent of the agent's final message, and missing evidence should never be presented as confirmed success.

Example workflow

Task: Follow up on overdue invoices

Assigned to: Finance

Expected behavior:

• Identify all invoices currently overdue.
• Exclude invoices that have already been paid.
• Avoid sending duplicate reminders.
• Send reminders only through the permitted mailbox and approval flow.
• Report any invoices that could not be processed.

Example verification report:

Invoice Reminder Task — Partially Completed

• 20 invoices evaluated
• 12 eligible reminders identified
• 11 reminders successfully sent
• 1 reminder held for review
• 0 duplicate sends detected

Needs attention: One customer's payment status could not be verified, so the reminder was not sent.

Instead of requiring the business owner to investigate what happened, Michael provides a short explanation supported by the available records.

The numbers above are an illustrative example of the proposed feature, not results from the current application.

Suggested implementation

I would start with one well-defined workflow instead of attempting to build a generic verification engine for every agent action.

Phase 1 — Small MVP

Use an invoice-reminder workflow with simulated invoice records and mocked email operations.

• Capture an expected-outcome definition when Michael creates the task.
• Record structured execution evidence, including invoice identifiers and email operation results.
• Create a small, read-only verifier that compares the results against the success criteria.
• Make verification idempotent so checking a task never repeats an email send or another side effect.
• Return a structured verification result containing the status, evidence, and any discrepancies.
• Show a concise verification summary in the existing task reporting experience.

The existing architecture provides possible integration points:

• src/main/hive.ts — agent coordination and task execution
• src/main/hooks.ts — agent lifecycle and tool events
• src/shared/ownerRequests.ts — owner request and task state
• src/shared/askMeRouting.ts — reporting results and escalating questions

These are suggested investigation points rather than confirmed implementation locations.

Phase 2 — Extend to other workflows

Once the first use case works reliably, reusable verification rules could support workflows such as:

• Customer support: confirm that a requested response was actually sent.
• Inventory: verify that updated stock quantities match the source records.
• Scheduling: confirm that an appointment exists without creating duplicates.
• Finance: reconcile processed transactions or invoice updates against expected totals.

For actions that cannot be independently verified, Michael should explicitly say so instead of reporting an unsupported success.

Alternatives considered

1. Trust the agent's completion message

This is simple, but an LLM can misunderstand a task, overlook failures, or report success based on incomplete information. Its final response should not be the sole source of truth.

2. Rely on existing execution logs and monitoring

Logs are useful for debugging, but they don't necessarily establish whether the intended business result was achieved. They also require the owner to investigate technical details.

3. Ask another LLM to judge whether the task succeeded

A second model could help interpret ambiguous results, but it can also make mistakes. For verifiable operations, deterministic checks against structured evidence should come first.

4. Require manual approval after every task

This gives the owner control but creates unnecessary interruptions. The existing approval mechanisms should remain responsible for authorizing actions; outcome verification should determine what happened afterward.

5. Build a general-purpose verification framework immediately

This would provide flexibility but introduce unnecessary complexity for an initial implementation. Starting with one concrete business workflow makes the feature easier to validate and improve.

Why I think this matters

What I like about Don't Be Michael is that it's designed for people who want to run their businesses, not spend their day supervising AI tools.

As the office becomes more autonomous, I think the distinction between execution success and verified business success becomes increasingly important.

The existing safeguards help control what agents are allowed to do and how they behave. Outcome Verification would complement those safeguards by checking whether the work actually achieved what the owner asked for.

I've been exploring a similar engineering problem through an Enterprise Transformation Validator I built, where I compare behavior before and after system changes to identify inconsistencies and provide evidence-based confidence scoring.

That's what made this opportunity interesting to me. I'd love to contribute to making AI automation not just more capable, but something small-business owners can confidently depend on.

Area

The hive (memory, routing, GOD agent)

Pre-flight

• Reviewed the existing architecture and related issues to check for overlapping proposals.
• A mockup or recording can be added separately to illustrate the proposed verification report.

Area

Office floor / avatars

Pre-flight

• I attached a screenshot, mockup or recording above.
• I searched existing issues and discussions, and this isn't a duplicate.