AIZOYA Operator for Alexa+

• 

  AIZOYA Operator — governed AI operations from intent to evidence

• 

  Approved work is assigned to a real owner

Inspiration

AIZOYA Operator for Alexa+ was inspired by a simple question:

What happens when an AI assistant moves from answering questions to helping carry out real operational work?

Alexa+ already provides powerful intelligence and orchestration. We saw an opportunity to add something different: an accountability layer for consequential business workflows.

The goal became clear:

Alexa+ provides the intelligence. AIZOYA adds the accountability layer.

That means helping ensure important work is not only suggested, but also approved by the right person, assigned to an owner, remembered across sessions, verified with evidence, and closed with proof.

We chose a restaurant operations scenario because it makes the challenge concrete. In our synthetic La Bandera Kitchen workflow, the system must determine whether the business is ready for Saturday preorders, identify inventory gaps, prepare a purchase plan, stop for human approval, preserve operational state, and verify completion.

What we built

AIZOYA Operator is a governed operations layer for Alexa+.

The hero workflow is:

Inventory gap → Purchase plan → Human approval → Staff handoff → Later-session risk brief → Evidence reconciliation → Verified Action Receipt

In the verified demo, AIZOYA:

• identified 3 synthetic inventory gaps
• created a versioned $66.00 purchase plan
• stopped at a visible human approval gate
• proved that selecting Not now results in no handoff
• accepted explicit human approval for the current plan
• handed approved work to the assigned staff owner
• preserved the operational state across a later session
• recognized that closeout evidence was still missing
• reconciled synthetic receipt evidence
• produced a final Verified Action Receipt only after deterministic verification

The product is designed around a few simple ideas:

• The AI cannot give itself permission.
• AIZOYA remembers the work, not just the conversation.
• It does not just say the job is done — it shows proof.

How we built it

The MVP was built with a deliberately small and auditable architecture.

Technical foundation

• Node.js 22
• MCP 2025-11-25 Streamable HTTP
• exactly 8 business-capability MCP tools
• atomic JSON-file persistence for synthetic local state
• tenant-partitioned state
• idempotency protection
• version-bound human approval
• SHA-256 evidence and state hashes
• deterministic evidence reconciliation
• local Alexa+ simulated web experience

The eight MCP tools are focused on business capabilities rather than vendor-specific integrations:

1. get_shift_brief
2. capture_commitment
3. reconcile_inventory
4. build_purchase_plan
5. approve_action
6. handoff_task
7. verify_closeout
8. get_action_receipt

This keeps the surface understandable and allows future integrations to sit underneath the business workflow without changing the operating model.

What we learned

One of the biggest lessons was that building something technically different is not enough — the difference must also be easy to explain.

For example, one of our technical concepts was “persistent operational state.”

That phrase is accurate, but not consumer-friendly.

We translated it into:

“AIZOYA remembers the work, not just the conversation.”

That became an important product lesson for us: simplicity has to apply not only to the interface, but also to how the value is communicated.

We also learned that the best positioning is not to compete with Alexa+.

Alexa+ already provides the intelligence and orchestration.

AIZOYA is designed to complement that by adding:

• approval
• ownership
• continuity
• verification
• proof

That distinction became central to the project.

Challenges we faced

The biggest technical challenge appeared during manual browser testing.

Our automated backend tests were passing, but the local browser demo initially failed because the server origin allowlist did not include the actual local judge UI origin.

The page loaded, but MCP requests from the browser were rejected.

We fixed the issue by:

• correcting the local origin allowlist
• adding a regression test for the judge UI origin
• hardening the web client so MCP and HTTP errors display their real error instead of failing with a generic JavaScript exception

After the fix, we reran verification and achieved:

• 13/13 automated tests PASS
• 10/10 consecutive isolated hero workflows PASS

We also manually verified the full browser path from approval through final evidence.

Another challenge was staying disciplined about what we could honestly claim.

The current build is intentionally a synthetic local Alexa+ simulation.

We do not claim:

• production Alexa+ integration
• live Amazon Bedrock orchestration
• production AWS infrastructure
• real purchasing
• supplier messaging
• Toast production integration
• SMS execution
• production authentication
• production database persistence

AWS and Bedrock integration are documented as architecture-ready, but they are not executed in the verified MVP.

Why it matters

As AI systems become more capable of taking action, the question is no longer only:

“Can the AI do this?”

The more important questions become:

• Was it authorized?
• Who owns the next step?
• What is still unresolved?
• Did the work actually happen?
• What evidence proves it?

AIZOYA Operator is our answer to that problem.

From conversation to controlled execution. From execution to evidence.

Built With

• action
• agentic
• agents
• ai
• alexa+
• approval
• automation
• context
• http
• human-in-the-loop
• idempotency
• isolation
• javascript
• json-rpc
• mcp
• model
• node.js
• operational
• protocol
• sha-256
• streamable
• tenant
• verified
• workflow
• workflows