Skip to main content
PlanVault.ai
PlatformCompareResourcesDocsAPISecuritySupport
PlanVault guides

Resources for governed AI execution

A single index of practical guides for teams connecting AI to production APIs, webhooks, MCP, knowledge bases, and operational systems without losing control.

Resource index

Guides for AI execution governance

Start with concepts, integrations, scale, compliance, cost, or runtime safety. Each card opens a short problem-led guide.

Concepts

The problem

An agent framework can reason well, but once the model moves toward action the business still needs runtime policy gates, audit, recovery, cost visibility, and a secrets boundary. If those controls live in prompt rules and callback code, it is hard to explain who allowed an action, which live parameters were checked, what ran, and how a run recovers after failure.

How PlanVault changes the approach

PlanVault keeps the LLM in the planner role: it proposes a plan, while a controlled runtime validates, evaluates live tool-call parameters, pauses or hard-denies, executes tool calls, journals transitions, and keeps secrets out of the prompt. Existing LangChain, LangGraph, MCP, or webhook stacks can be wrapped without moving all governance logic into the model loop.

Platform overviewDocs: architectureDocs: securityAPI docs

What to verify in the product

Use /platform for the buyer-facing map, /docs/architecture for runtime boundaries, /docs/security for the secret and data model, and /api-docs for the Runtime API that external systems use to start governed sessions.

Integration

The problem

Teams often have REST APIs, inbound webhooks, outbound callbacks, MCP servers, knowledge sources, and low-code automations as separate surfaces. Without one execution surface, each integration needs custom glue for auth, retries, audit, secrets, and diagnostics.

How PlanVault changes the approach

PlanVault normalizes those surfaces into one tool catalog and runtime: OpenAPI imports, MCP tools, webhooks, Knowledge Base, and session metadata pass through shared policy, secret, routing, audit, and recovery boundaries.

Platform integration mapDocs: APIAPI docs

What to verify in the product

On /platform, the Integration Surfaces section shows inputs, the control layer, and outputs. /docs/api and /api-docs show the Runtime API, webhooks, and public contract for integrations.

The problem

A one-time OpenAPI import goes stale quickly: schemas change, base URLs differ between staging and production, auth conventions evolve, and tool definitions in planner context can lag behind reality.

How PlanVault changes the approach

PlanVault treats OpenAPI as a lifecycle: source records, sync preview, sync runs, runtime URL overrides, and Auto-Healer help keep the catalog current without hand-editing every tool.

Docs: APIDocs: architecture1,000 endpoints guide

What to verify in the product

Review the docs/API and architecture sections for import and sync concepts, then read the 1,000-endpoints guide because catalog lifecycle and retrieval scale work together.

Scale

The problem

When a tool catalog grows to hundreds or thousands of endpoints, dumping definitions into the prompt increases tokens, noise, and wrong-tool selection risk. Manually splitting agents by domain quickly becomes operational work.

How PlanVault changes the approach

PlanVault builds the shortlist before the planner call: adaptive retrieval, scenarios, Suggested Patterns, and Semantic Routing Cache choose relevant tools inside the org/project boundary. The model sees less noise, while the runtime stays responsible for execution.

Docs: architecturePlatform integration mapOpenAPI lifecycle guide

What to verify in the product

Review /docs/architecture for the retrieval pipeline, /platform for the integration map, and /resources#openapi-sync-lifecycle for how the catalog stays current after OpenAPI import.

Compliance

The problem

AI workflow history often lives outside the main application database: prompts, tool calls, approvals, callbacks, diagnostics, and audit records can contain personal data or pseudonymous external-user references. A GDPR request does not stop at one user table.

How PlanVault changes the approach

PlanVault ties sessions to org/project/externalUserId context, encrypts history, supports retention, and exposes export/delete flows for AI run history. It does not replace the controller’s legal process, but it gives the technical surface needed to execute the request.

Docs: securityPlatform overviewDocs: API

What to verify in the product

Review /docs/security for encryption, retention, and data-subject flows, /platform for the deployment boundary, and /docs/api for technical export/delete endpoints.

Cost

The problem

LLM cost grows for reasons beyond expensive models. Prompt bloat, irrelevant tool definitions, large schemas, repeated replans, and missing attribution make spend hard to explain to finance or platform teams.

How PlanVault changes the approach

PlanVault reduces work before the planner call through tool shortlists, scenarios, routing cache, and bounded evidence. After execution, usage ties back to org/project/session context, tags, and workflow metadata for chargeback and budget discussions.

Compare approaches1,000 endpoints guideDocs: architecture

What to verify in the product

Use /compare for category-level tradeoffs and the console spend/budget screens for operational controls. On the public side, the principle is simple: less irrelevant context before the model, more attribution after execution.

Runtime safety

The problem

When AI starts business actions, a retry, duplicate callback, or partial failure can repeat a mutation. A prompt instruction saying “do not repeat” is not a recovery strategy, and scattered logs do not give a full incident record.

How PlanVault changes the approach

PlanVault uses Idempotency-Key, an event-sourced FSM, explicit lifecycle states, approvals, and diagnostics/replay. The model proposes the plan, but the runtime controls side effects and recovery.

Docs: architectureDocs: securityAPI docs

What to verify in the product

Review /docs/architecture for FSM and replay, /docs/security for policy/data boundaries, and /api-docs for idempotent Runtime API contracts.