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
Agent Platform Overview	Customer-facing platform model	How do configured agents, tool binding, review gates, and audit fit together?
Agent Hub	Tenant-facing agent entry point	How do users find available agents, check data health, and enter workflows?
Agent Lifecycle and Configuration	Agent setup and change control	How should teams plan, configure, validate, change, and retire an agent?
Risk Governance and Safety	Risk levels and review gates	Which outputs require evidence, audit, confirmation, human approval, or policy control?
Runtime Tool Discovery	Tenant-visible tool access	Which tools can this client, key, tenant, and agent see at runtime?
Tool Execution Governance	Tool call outcomes	How are allowed, confirmed, pending, blocked, and audited outcomes handled?
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 release 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 configured agent, Agent Hub entry, 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	Agent binding, 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 Agent Platform Overview if the team needs the governed runtime model. Start with Runtime Tool Discovery if the next decision is about visible tools. Start with Tool Execution Governance if the next decision is about allowed, confirmed, pending, blocked, or audited outcomes.

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 these fields are still unclear, return to the architecture and capability pages before starting implementation work.