AI Agents
AI Agents is the controlled orchestration ledger for AI-assisted work. It records what an agent session intended to do, which plan and steps were reviewed, which registered tool or action asset was referenced, which human gate or source-owner decision applied, and why work stopped when policy, provider, budget, evidence, reviewer, or source-owner posture blocked progress.
The agent ledger does not replace owning modules. It does not write findings, risks, controls, documents, obligations, incidents, evidence, assurance, or lifecycle records directly. Final records still move through the owning module, its permission checks, command seam, lifecycle rules, approval requirements, and audit trail.
What You Can Record
| Record | Use it for |
|---|---|
| Agent session | Capture a governed run/session boundary, source refs, AI system refs, retrieval policy refs, Review Approval refs, policy snapshot, human-gate snapshot, limitations, evidence refs, and stop condition. |
| Agent plan | Capture an ordered plan with action intent, source refs, retrieval policy refs, Review Approval refs, policy decision, human-gate posture, limitations, evidence refs, and approval status. |
| Agent plan step | Capture observe, reason, retrieve, draft, compare, recommend, request approval, execute action, wait, stop, rollback, or handoff steps with target refs and result refs. |
| Agent tool call | Capture controlled tool-call intent and result references over registered tool or action assets. |
These records are useful when AI-supported workflows need a reviewable trail before a human or owning module decides what should happen next.
When a session, plan, step, or tool call reaches an actionable state such as
active, waiting for human approval, approved, blocked, completed, or executed,
AI records a sanitized Governance Trace decision receipt. Draft and planned
records remain editable ledger entries and do not create receipt noise.
The same agent events project into the workspace audit stream, so Activity,
audit packages, work descriptors, and posture consumers use safe event metadata
instead of raw prompts, source content, or provider payloads.
Session and plan records also carry first-class retrieval policy and Review
Approval instance references. Those refs are validated before persistence,
linked into Governance Trace receipts, shown in the AI Agents workbench, and
published through audit-package export descriptors.
For plans that need a human gate, an operator can request a Review Approval
directly from the plan. AI links the resulting review instance to the plan and
moves the plan into waiting_for_approval; Review Approval remains the source
of truth for the human decision.
The AI Agents workbench also shows compact Evidence columns on plan, step, and tool-call rows. These columns summarize counts and flags for source refs, human gates, limitations, evidence or result refs, policy decisions, budget refs, input and output refs, owner results, stop conditions, and errors. They are a reviewer aid; they do not expose raw prompt text, raw source text, provider output, connector payloads, vectors, embeddings, secrets, or credentials.
Safe Evidence Boundary
Agent records should contain refs, states, hashes, policy summaries, decision keys, and evidence references. They should not contain raw prompts, source text, provider payloads, vectors, credentials, storage paths, private notes, or unredacted extracted values.
If a workflow needs source content, use the approved source module, context retrieval, document intelligence, or evidence display seam. The agent ledger stores the safe reference to that source, not the source itself.
Typical Workflow
- Open AI Agents from the AI Governance navigation.
- Record an agent session for the governed source area and AI system.
- Record a plan with an action intent and human-gate posture.
- Request Review Approval from the plan when controlled execution requires a human gate.
- Record ordered steps that explain how the work was observed, reasoned over, retrieved, drafted, recommended, approved, executed, stopped, rolled back, or handed off.
- Record tool-call intents only for registered tool/action assets and keep result data as owner refs.
- Use stop conditions when policy, provider, profile, deployment, budget, stale source, missing evidence, reviewer rejection, or source-owner decision blocks progress.
- Transition steps and tool calls only after the required review, policy, classification, retention, and source-owner decisions are recorded.
- Let the owning module apply any final state change through its own workflow.
Transition And Apply Targets
Operators with AI governance management permission can transition agent steps and tool calls from the AI Agents console. The transition captures the new state, stop condition where applicable, safe decision snapshots, timestamps, and owner result references. Terminal rows stay read-only in the console, and server-side lifecycle rules remain the authority.
For material actions, approving a plan is not enough by itself. The tool call must also carry non-blocking action-policy, source-owner, classification, and retention decisions. Only then can an operator use Apply target to send the reviewed, sanitized value and application snapshot through a registered owning module target applier. The AI ledger records the controlled tool-call outcome; the owning module persists the final control, finding, risk, obligation, document, evidence, or lifecycle record according to its own workflow.
Use Run governance preflight before applying a tool call. The preflight derives the tool call’s grounding, citation/provenance posture, lineage, action-policy decision, source-owner/resource-access decision, target-applier fit, classification, retention, and budget posture from existing product records. Tool calls cannot execute or apply to a target unless that generated preflight is allowed, and operators cannot replace it with caller-supplied decision text.
Use this path for governed handoffs. Do not paste raw prompts, source text, provider responses, connector payloads, credentials, or storage locations into the value or application snapshots.
Project Follow-Up Work
Use Project work when the agent ledger contains items that need operator follow-up. Novantra projects eligible agent sessions, plans, and tool calls into central Work Management using AI-owned work-item descriptors:
- sessions with stop conditions, blocked, failed, stopped, or waiting states become triage work;
- plans waiting for approval become human-gate review work; and
- tool calls waiting for approval become tool-result review work.
Completed, archived, approved, executed, or otherwise non-actionable rows are skipped. The projected work item stores safe refs, status and decision metadata, assignment hints, priority hints, and a route target back to the AI agent ledger. It does not copy raw prompts, source text, provider responses, connector payloads, storage keys, credentials, or owning-module record bodies.
Work Management owns the follow-up work item. AI remains the ledger of the agent session, plan, step, or tool call. The owning source module remains the only place where a final control, risk, finding, document, evidence, lifecycle, or obligation record is created.
Cloud And On-Prem Parity
Cloud and on-prem deployments expose the same AI agent ledger behavior. The deployment determines provider connectivity, runtime availability, credentials, and storage controls, but the product contract is the same: safe refs, governed reasons, audit evidence, activity presentation, work candidates, posture signals, and audit-package export descriptors are available in both deployment tracks.
On-prem no-AI profiles physically exclude the AI feature routes and UI. In those deployments, use the owning module’s manual review and workflow paths instead of hidden AI execution. No-AI mode must not create agent plans or tool calls behind the scenes.