Day-0 Guide
General enterprise visibility, with access to the enterprise's general document spaces. No HR or payroll compartment access.Viewing as Enterprise Reader
Chapter 12 of 13FUTURE DIRECTION

What if AI can do more than answer?

EKA primarily introduces the idea of AI reading, retrieving and reasoning over the enterprise.

A later step is an enterprise agent that may also participate in business work.

That changes the architecture substantially.

Understand

Read/reason vs act

EKA-style interaction
  1. READ
  2. RETRIEVE
  3. REASON
  4. ANSWER
Agent-style interaction
  1. OBSERVE
  2. REASON
  3. DECIDE / PROPOSE
  4. ACT

The important new word is:

ACT

because actions can change enterprise state.

The rule that should not change

A future agent should not gain arbitrary database write access.

It should use the same controlled business mutation path as other callers.

Human UI
Integration
Simulator
Agent
Command / Handler

The caller may be intelligent.

The enterprise rules still belong to the handler.

Why this matters

Suppose an agent decides:

an invoice is overdueand a follow-up action is appropriate

The unsafe approach would be:

agent → directly edit ERP tables

A safer enterprise architecture is:

agent observes
agent reasons
approved action selected
business command invoked
authorizationvalidationidempotencyauditsource mutationevent
downstream enterprise progression
See it in Metrolane

Use the existing mutation architecture

The Day-0 Explorer does not currently expose an agent-action record.

So the Guide should not fabricate one.

Instead, show the already established command/handler path and explain:

Future agents would enter through this same governed business boundary.
Important distinction

Agent does not mean unrestricted autonomy

Enterprise agents may eventually operate at different levels.

For example:

observe onlyrecommendprepare actionrequest approvalact within delegated authority

The Guide should not claim one final autonomy model until agent architecture is deliberately designed.

Business time still matters

If an agent acts inside a simulated runtime, the action still occurs in enterprise business time.

Its consequences may still:

  • create source changes
  • trigger events
  • become relay work
  • be extracted later
  • reach canonical later

An agent does not bypass the runtime model.

Provenance becomes even more important

When AI can change state, the enterprise should be able to answer:

  • Which agent acted?
  • What did it observe?
  • Which action did it invoke?
  • Under whose authority?
  • What command executed?
  • What event resulted?
  • What changed downstream?

The existing command/audit/event architecture is the foundation for that future capability.

Go deeper

A future action loop

A future action loop
OBSERVEcanonical enterprise · documents · events · runtime state
REASONgoal · policy · constraints · available actions
DECIDE / PROPOSE
APPROVALwhere required
ACTbusiness command / handler
ENTERPRISE CHANGEsource-system state · events · relays · connector/projection

This is a future architecture direction.

It is not current Day-0 functionality.

Chapter takeaway

  • EKA reads and reasons.
  • Future enterprise agents may also act.
  • Actions should still pass through commands and handlers.
  • AI should not bypass authorization, validation, idempotency or audit.
  • The agent becomes another governed participant in the enterprise.