AI Agent Architecture and Reference

Use this section when a team needs to understand how FactVerse AI Agent is structured before designing a workflow, integration, or deployment model. These pages define the product boundaries, architecture layers, capability areas, and documentation structure used by the rest of the docs.

Reference selection flow

Reference map

Page	Use it for	Main questions answered
Core Concepts	Shared vocabulary for agent workflows	What is an endpoint, tool, scope, tenant context, source reference, and approval boundary?
Architecture	Runtime and product responsibility model	How do clients, MCP, Platform, DFS, Designer, Inspector, knowledge, and simulation services work together?
Capability Map	Capability planning and roadmap discussion	Which capability groups support facility operations, predictive maintenance, and Physical AI workflows?
Documentation Architecture	Documentation ownership and expansion planning	Which pages should be written next, and which content belongs in product manuals or workflow guides?

When to use this section

• Designing a new AI client or enterprise agent integration.
• Deciding which FactVerse product owns a workflow capability.
• Planning data, simulation, inspection, or work-order boundaries.
• Reviewing whether a workflow should use a base MCP endpoint or a module endpoint.
• Checking whether a page belongs in concept docs, operating guides, workflow guides, use cases, or reference material.

Architecture checklist

Area	Check before design moves forward
Product context	The workflow identifies which roles belong to Platform, DFS, Designer, Inspector, MCP, and connected systems.
Tenant boundary	The client has a clear tenant, site, asset group, and permission boundary.
Data boundary	Required signals, documents, scenes, and work records have owners and freshness expectations.
Tool access	Tool discovery, scopes, and approval controls are planned before implementation.
Output evidence	The workflow can return source references, assumptions, and review notes.
Operating handover	The operating team knows how workflow runs, exceptions, and feedback will be recorded.

Next step

Start with Core Concepts if the team needs vocabulary alignment. Start with Architecture if the next decision is about integration boundaries or deployment planning.

Expected output

After using this section, the team should be able to write a short design note that states:

• workflow owner and operating boundary;
• product surfaces involved;
• source data and scene context needed;
• MCP endpoint and scope assumptions;
• approval and audit requirements;
• documentation pages that need to be linked from the final runbook.

Review handoff

Use the design note as the handoff between product planning, integration engineering, and operations. A useful handoff should name the next document owner and the next validation step.

Handoff item	Example decision
Product owner	Which product surface owns the capability or user-facing workflow.
Integration owner	Which team configures MCP, DFS, source systems, or customer network access.
Data owner	Which person confirms data freshness, identity mapping, and quality limits.
Reviewer	Which operator, engineer, facility owner, or compliance owner accepts the output.
Next document	Workflow guide, module page, DFS recipe, MCP guide, or customer runbook.

If the team cannot fill these fields, return to the architecture and capability pages before starting implementation work.