Choose the surface and authority level first
A use case needs explicit data, model, tools, human decision, evidence chain, evaluation, retention, fallback, and owner.
Bounded answer
A typed AI framework and focused agents, not one autonomous ERP agent
Reviewed source includes focused catalog and customer agents, typed tools, structured output, provider/model controls, conversations, token telemetry, loop budgets and staged typed mutations. Legacy Code Mode and external MCP are separate surfaces. Safe production use still requires effective configuration, data and authority controls, evaluation, recovery and accountable ownership.
- Reviewed
- 2026-07-14
- Revision
- 01911d00e28f44cf484d0b1d04860dcfef5370bf (v0.6.5-1202-g01911d00e)
- Latest tag and package
- v0.6.5 · @open-mercato/ai-assistant 0.6.5
Current source differs materially from the tag; current behaviors below are not silently labeled as v0.6.5.
Seven AI surfaces and authority contracts
available
AI-assisted engineering
- User and entry point
- Developers and coding agents · Repository guidance and generators
- State, data and context
- Repo and spec context; no operator business state
- Tools and authority
- Coding tools only
- Approval
- Code review and delivery gates
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Repository and delivery evidence
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Not the in-app assistant or correctness proof · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
configurable
Legacy OpenCode Code Mode
- User and entry point
- Authorized operator · Legacy chat endpoint and sandbox
- State, data and context
- OpenAPI context and selected application data
- Tools and authority
- GET plus capped POST, PUT, PATCH and DELETE under endpoint RBAC
- Approval
- Prompt instructs AskUserQuestion before writes; no typed pending-action card
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Legacy conversation and API evidence
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Prompt confirmation is not a server-staged approval · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
available
Typed in-app agents
- User and entry point
- Feature-authorized operator · AiChat and global launcher
- State, data and context
- Tenant/org/user context, conversation, page and attachments
- Tools and authority
- Agent-allowlisted typed tools
- Approval
- Effective mutation policy and pending card where applicable
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Server conversation, pending action and events
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Focused catalog/customer agents only · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
configurable
Structured-object execution
- User and entry point
- Programmatic caller · Typed runtime object mode
- State, data and context
- Schema-bound input and context
- Tools and authority
- Allowlisted tools if declared
- Approval
- Caller-owned review and business gate
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Schema result and application evidence
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Not an automatically available manager workflow · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
integration-required
External MCP clients
- User and entry point
- External authenticated client · Dev, HTTP or stdio tool server
- State, data and context
- Session/API-key scope and exposed tool context
- Tools and authority
- Tools, not in-app agent orchestration
- Approval
- Client-specific approval required
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Transport logs, tool evidence and reconciliation
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Does not inherit agent prompt, loop or approval card · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
configurable
Model/provider configuration
- User and entry point
- AI administrator · Environment, tenant and agent settings
- State, data and context
- Provider/model/base URL class and allowlists
- Tools and authority
- Model inference
- Approval
- Configuration review, not business approval
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Effective-config snapshot and usage events
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- No quality, geography, privacy, uptime or capacity assurance · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
custom
Custom bounded agent
- User and entry point
- Module developer and owner · AiAgentDefinition and typed tools
- State, data and context
- Purpose-specific data, prompts, tools and UI
- Tools and authority
- Reviewed allowlisted tools
- Approval
- Designed mutation and human policy
- Identity, scope and persistence
- Tenant, organization, user and feature context where applicable · Tests, deployment, evaluation and operations
- Owner and manager decision
- Name the surface owner and decide whether this authority fits the use case.
- Evidence and limitation
- Requires complete lifecycle ownership · current source at 01911d00e28f44cf484d0b1d04860dcfef5370bf · 2026-07-14
Do not collapse these layers
- 1
AI-assisted engineering is not the operator assistant
- 2
MCP serves tools, not in-app agents
- 3
An LLM answer is not a tool result
- 4
Approval is not execution
- 5
Execution is not external acknowledgement
- 6
An event is not reconciliation
- 7
Token or loop telemetry is not quality evidence
Current reviewed agent inventory
Catalog Assistant
Explore products, categories, variants, prices, offers, media, tags, schemas and units
- Domain
- catalog
- Read/write posture
- read-only
- Required feature family
- catalog view features
- Media and loop
- bounded media · no mutation
- Page context
- catalog page context
- Limitation and review date
- Not a universal catalog decision maker · 2026-07-14
Catalog Merchandising Assistant
Draft copy, attribute and price proposals and call named catalog writes
- Domain
- catalog
- Read/write posture
- write-capable
- Required feature family
- catalog view/manage features
- Media and loop
- bounded media · confirm-required
- Page context
- selected catalog context
- Limitation and review date
- Approval card does not prove every record changed correctly · 2026-07-14
Customers Account Assistant
Explore accounts, people, deals, activities and propose named CRM writes
- Domain
- customers
- Read/write posture
- write-capable
- Required feature family
- customer view/manage features
- Media and loop
- bounded media · confirm-required
- Page context
- account context
- Limitation and review date
- Focused CRM scope only · 2026-07-14
Deal Analyzer
Bounded multi-step deal analysis and one stage-change proposal
- Domain
- customers
- Read/write posture
- write-capable demo
- Required feature family
- customers.deals.view
- Media and loop
- none material · loop budget and confirm-required
- Page context
- deal context
- Limitation and review date
- Demonstration, not business judgment assurance · 2026-07-14
ToolLoopAgent sibling
Mutation-gate proof scenario
- Domain
- customers
- Read/write posture
- proof sibling
- Required feature family
- test scenario
- Media and loop
- none · tool-loop-agent
- Page context
- proof context
- Limitation and review date
- Do not market as a production business assistant · 2026-07-14
Module-owned agent contributions were found in catalog and customers only. Additional domain or cross-domain agents remain custom until refreshed evidence proves otherwise.
Use-case decision tree
- business decision
- acceptable error
- reversibility
- data class
- model and provider
- grounding source
- tool authority
- write or destructive action
- human decision point
- external systems
- latency
- volume
- explanation needs
- audit evidence
- retention
- evaluation set
- fallback
- recovery
- accountable owner
1. read-only assistance
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
2. structured extraction or classification
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
3. confirmed in-app mutation
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
4. deterministic workflow or rule instead of AI
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
5. custom bounded agent
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
6. external MCP or tooling with separate controls
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
7. stop or defer
Choose only when data class, acceptable error, authority, evidence, evaluation, retention, fallback, recovery and owner are explicit.
Model, prompt, data and storage controls
1. use-case purpose
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
2. data inventory
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
3. classification
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
4. minimization
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
5. source of truth
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
6. prompt and context construction
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
7. retrieval
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
8. attachments
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
9. provider and model
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
10. region
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
11. supplier terms
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
12. training and retention assumptions
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
13. secrets
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
14. encryption boundary
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
15. logs
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
16. conversation storage
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
17. sharing
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
18. deletion
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
19. retention
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
20. data-subject handling
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
21. exit and portability
Record the effective source and configuration, accountable reviewer, test, retention or deletion evidence, change gate and stop condition.
Configuration and allowlists constrain what may run; runtime precedence selects the effective provider/model. Local adapters are possible. None proves model quality, geography, privacy terms, support, uptime or capacity. Prompt overrides append to code-owned sections and are versioned; prompt text is not authorization. Capture an effective-config snapshot with agent, prompt version, provider, model, gateway class, allowed tools, mutation policy, loop limits and review owner.
Authority ladder
1. answer
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
2. suggestion
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
3. structured proposal
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
4. read tool
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
5. mutation proposal
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
6. confirmed mutation
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
7. destructive mutation
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
8. external side effect
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
9. cross-system acknowledgement
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
10. reconciliation
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
11. business sign-off
Name who may initiate and approve, the technical gate, captured evidence, recovery, residual risk and a stop condition.
Typed mutation, Code Mode and MCP boundaries
Under confirm-required, a correctly declared isMutation typed tool becomes a pending action with normalized input, optional preview/version, idempotency key and expiry. Confirmation or cancellation rechecks status, access, allowlist, effective policy, attachments, schema and available record version before the handler. Under destructive-confirm-required, non-destructive mutations can execute directly. read-only filters mutation tools. Preview and stale checks exist only when resolvers and versions are supplied. The pending repository state is separate from the business handler transaction, and approval is not a distributed transaction or external-delivery proof.
Code Mode blocks raw fetch, require, process and filesystem globals, applies time and call caps, checks endpoint RBAC and refuses featureless mutations unless explicitly opted in. It supports write methods and uses prompt-level AskUserQuestion guidance, not the typed pending-action card. MCP exposes tools through dev, HTTP or stdio transports with different key/session paths. It requires least privilege, rotation, revocation, client trust, transport protection, logging and incident response. The explicit unauthenticated-super-admin development escape hatch must never become production policy.
Attachments, conversations, retention and telemetry
Attachments are scope-checked and may reach the configured model as inline bytes, signed URLs, extracted text or metadata-only fallback. Accepted media does not replace data classification, minimization, malware handling, supplier/region review, signed-URL policy, retention and deletion tests. Conversations, participants and messages persist server-side with tenant/org scope, owner, visibility, UI parts, attachment ids, model metadata and soft deletion; sharing is feature-gated. Any local-only history statement is documentation drift. The default 90-day token-event pruning rule does not define conversation or attachment retention. Token counts and loop traces support operations, not monetary cost, accuracy, safety or business outcome.
Evaluation and model-change pack
1. representative golden set
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
2. edge cases
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
3. correct abstention
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
4. tool selection
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
5. retrieval grounding
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
6. scope denial
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
7. prompt injection
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
8. indirect injection in attachments
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
9. cross-tenant attempts
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
10. unauthorized tools
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
11. mutation previews
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
12. stale records
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
13. duplicates
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
14. timeouts
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
15. provider failure
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
16. loop budget
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
17. cancellation
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
18. recovery
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
19. human review
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
20. model and release change regression
Set project-specific expected behavior, measurable threshold where meaningful, evidence, reviewer and failure response. Rerun when source, model, provider, gateway, prompt, tools, policy, retrieval, attachments or data contracts change.
Operating controls and responsibilities
- provider health
- request errors
- latency
- tokens
- loop stops
- tool failures
- pending actions
- expired or failed actions
- stale rejects
- unauthorized attempts
- conversation sharing
- retention jobs
- unusual volume
- external acknowledgement
- reconciliation
- incident response
- fallback
- kill switch
- owner
- backup owner
- business use-case owner
- data owner
- process owner
- model/provider owner
- agent/tool owner
- application owner
- identity and access owner
- security/privacy owner
- evaluation owner
- operations/on-call owner
- human approver
- internal audit or risk reviewer
- external-system owner
Three synthetic examples
Hypothetical only
Synthetic read-only account research
The canvas exposes product contribution, configuration/custom work, data class, authority, human decision, evidence chain, failures, tests, owners and stop.
Hypothetical only
Synthetic approved catalog change
The canvas exposes product contribution, configuration/custom work, data class, authority, human decision, evidence chain, failures, tests, owners and stop.
Hypothetical only
Synthetic deferred cross-system action
The canvas exposes product contribution, configuration/custom work, data class, authority, human decision, evidence chain, failures, tests, owners and stop.
Local planning tool
AI use-case control canvas
Completeness is not a risk grade, provider recommendation, readiness score or go/no-go verdict.
Do not enter real data: Do not enter real prompts, personal, customer or employee data, secrets, credentials, record ids, confidential policies, provider keys, production URLs or incident details. Use synthetic labels only.
Privacy: this page does not submit worksheet content, place it in the URL, or store it in cookies.
Acceptance evidence chain
- 1
user intent
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 2
selected data
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 3
prompt and context
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 4
model response
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 5
tool proposal
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 6
human approval
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 7
handler execution
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 8
domain evidence
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 9
external acknowledgement
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 10
reconciliation
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 11
retained evidence
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 12
fallback
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
- 13
business sign-off
Record expected state, prohibited action, evidence, fallback, recovery owner and sign-off authority.
Stop conditions
- high-impact decision without qualified human authority.
- irreversible action without recovery.
- hidden or unreviewable change.
- unrestricted cross-domain tools.
- secrets or unnecessary personal data in prompts.
- missing supplier review.
- no evaluation set or abstention behavior.
- no audit or incident owner.
- no safe fallback.
- deterministic code or workflow is the better fit.
Method and limitations
Evidence was refreshed at the exact revision across agent and tool definitions, effective policy, model factory, prompts, mutation preparation/rechecks/execution, Code Mode, MCP transports, attachments, conversations, sharing, token retention and current catalog/customer contributions. Source differs from effective configuration. Model variability, supplier responsibility, custom tools, transport differences, soft deletion, missing deployment evaluation, privacy, security, cost, support and outcome remain project responsibilities.
Method, assumptions and limitations
Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.
This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.
Primary source collections: code repository, documentation, public releases.