FactVerse AI Agent Examples

These examples show how implementation teams can structure requests, tool flow, responses, and review records. The exact tool names should come from runtime MCP tool discovery for the target deployment.

The IDs below are examples only.

Example structure

Every example should keep four parts visible:

Part	Purpose
Request	What the user or system is asking the Agent to support.
Context	Tenant, site, asset, scene, time range, endpoint, and scopes.
Tool flow	Runtime-discovered tools used to read data, compute results, or prepare drafts.
Reviewed output	Summary, evidence, limitations, and the human review or approval state.

Facility operations alarm review

Use this pattern when an operator asks for alarm context and the next inspection step.

Request

Review the last 24 hours of pump alarms in Building A utility room U-02.
Show affected assets, recent inspections, open work orders, and suggested field checks.

Context

Field	Example value
Endpoint	/mcp/base/
Scopes	base.read; add base.action.write only for approved drafts
Asset boundary	Site SG-01, area U-02, equipment group PUMP
Source records	Platform assets, Inspector alarms, inspections, work orders, DFS signal timestamps

Tool flow

1. List available tools at runtime.
2. Select an asset or facility status tool with base.read.
3. Resolve the asset IDs for the requested room and equipment group.
4. Retrieve alarm history, inspection records, open work orders, and relevant documents.
5. Prepare a summary with source timestamps and missing-data notes.
6. If approved, draft an inspection task with the affected asset, location, reason, and suggested checks.

Reviewed output

{
  "summary": "Three pump-related alarms were recorded in U-02 during the review window.",
  "affected_assets": ["PUMP-U02-01", "PUMP-U02-03"],
  "evidence": [
    "Inspector alarm records from 2026-06-03T10:00:00Z to 2026-06-04T10:00:00Z",
    "Open work order WO-1024 for PUMP-U02-01",
    "Last inspection checklist INS-7781"
  ],
  "suggested_checks": [
    "Confirm vibration and bearing temperature on PUMP-U02-01",
    "Check valve position and recent restart logs for PUMP-U02-03"
  ],
  "review_state": "operator_review_required"
}

Predictive maintenance health review

Use this pattern when a maintenance engineer asks why an asset was flagged by the predictive maintenance module.

Request

Explain the current health change for compressor CMP-18.
Compare recent signals with maintenance history and recommend the next engineering check.

Context

Field	Example value
Endpoint	/mcp/pdm/ for health context, /mcp/base/ for documents and work records
Scopes	pdm.read, base.read; add base.action.write only for reviewed drafts
Asset boundary	Equipment CMP-18, line L2, review window 14 days
Source records	Signal history, anomaly output, maintenance history, inspection notes, manuals

Tool flow

1. Use runtime discovery on /mcp/pdm/ and confirm predictive maintenance tools are visible.
2. Retrieve the health summary, anomaly window, and key signal changes.
3. Use /mcp/base/ to retrieve equipment identity, work history, inspection notes, and documents.
4. Compare model output with recent maintenance and known operating changes.
5. Return ranked engineering hypotheses with evidence and confidence limits.
6. Route any follow-up inspection as a draft for engineer approval.

Reviewed output

{
  "asset": "CMP-18",
  "health_change": "Degrading trend detected over the last 9 days",
  "supporting_evidence": [
    "Discharge temperature trend increased above the asset baseline",
    "Vibration signal shows intermittent spikes during high-load periods",
    "No completed maintenance record after the last inspection note"
  ],
  "possible_causes": [
    {
      "cause": "Cooling or load-related operating condition",
      "confidence": "medium",
      "next_check": "Review cooling water flow and operating mode during spike windows"
    },
    {
      "cause": "Early bearing wear",
      "confidence": "low",
      "next_check": "Confirm vibration spectrum during the next field inspection"
    }
  ],
  "review_state": "maintenance_engineer_review_required"
}

Physical AI scene readiness review

Use this pattern when an engineering team needs to decide whether a Designer scene and SimReady assets are ready for simulation, process planning, or robot-training context.

Request

Check whether packaging line scene PKG-L1 can be used for a robot pick-and-place simulation.
List missing SimReady metadata and validation notes before running the compute job.

Context

Field	Example value
Endpoint	/mcp/base/ plus enabled simulation services
Scopes	base.read, base.compute.run; add base.action.write only for approved scenario records
Scene boundary	Designer scene PKG-L1, version v12, robot cell RC-03
Source records	Scene version, asset versions, SimReady metadata, task sequence, safety zones, validation notes

Tool flow

1. Resolve the scene version, asset IDs, coordinate system, and target task.
2. Check geometry scale, collision shapes, materials, articulations, motion limits, and required behavior metadata.
3. Attach operational constraints such as safety zones, task sequence, and expected cycle range.
4. Return a readiness report before starting compute.
5. Run approved simulation or rendering compute only after the engineering owner accepts the assumptions.
6. Record the scenario package, result version, limitations, and reuse path.

Reviewed output

{
  "scene": "PKG-L1",
  "scene_version": "v12",
  "readiness": "needs_repair_before_compute",
  "ready_assets": ["CONVEYOR-01", "ROBOT-RC03", "GUARD-FENCE-02"],
  "repair_items": [
    "BOX-STACK-04 is missing collision metadata",
    "GRIPPER-02 is missing articulation limits",
    "Safety zone SZ-03 requires confirmation from the engineering owner"
  ],
  "next_action": "Update SimReady metadata, then rerun readiness review",
  "review_state": "engineering_owner_review_required"
}

Example review checklist

• The endpoint and scopes are explicit.
• The workflow records source systems and timestamps.
• The response separates evidence from assumptions.
• Draft actions are clearly marked before approval.
• The final record captures the reviewer, decision, and follow-up path.