Credentials outside the agent
Broker target-scoped credentials without putting them in prompts or business payloads.
API Client Builder
Connect the API.
Govern the operation.
Turn existing services into reusable capabilities with explicit request and response contracts, mappings and runtime controls.
Define each operation visually: inputs, outputs, field mappings and whether it reads or writes. Frozion brokers scoped credentials, carries the requester’s authority and connects the client to the workflows that use it.
SUPPLIER SERVICE · CLIENT v3
Update supplier account
PATCH
/suppliers/{supplierId}/bank-account
Declared inputssupplierId stringproposedAccountRef stringexpectedRevision integer
Completion outputsupdatedRevision integerupdateStatus enumValidate the response before its values enter the next
step.
CONFIGURED EXECUTION BOUNDARIES
Caller scopePolicy & approvalOperation identityEffect evidence
Connect the technical contract to the business action
Typed inputs & outputsExplicit mappingsPer-step RBAC & policyHITL + FIDO2Durable executionInspectable evidence
API Client Builder across your adoption path
Govern existing agents
Expose a protected enterprise operation with declared inputs, outputs and authority.
Grow tools into workflows
Use reusable API clients and mappings within a visually defined workflow.
Build native agents
Native agents invoke the same registered API capabilities within their scope.
Build systems of engagement
Connect application processes to permitted reads and writes in existing systems.
The problem this solves
A connection is only part of an accountable API action.
The integration also needs to preserve who requested the work, how fields are mapped and what the destination’s response actually establishes.
Visible field mappings
Inspect the request and response contracts before another workflow depends on them.
A timeout has a meaning
Retain the uncertain result and reconcile the target before repeating a consequential write.
Keep the systems you already trust
Reuse enterprise services.
Carry their meaning into AI
work.
Your ERP, CRM, risk service or internal API can keep the responsibility it already owns.
Frozion connects those services to an application process that understands who requested the work, which resource is in scope, what the call is meant to do and which obligations apply.
An existing agent can invoke a complete Frozion workflow as a tool. That workflow can call several APIs, calculate facts, evaluate policies, pause for a person and return a governed result—while the agent keeps its current language and framework.
ENTRY POINTExisting agent or native application
GOVERNED WORKFLOWFacts, policy, human decisions and API operations
SYSTEM OF RECORDAuthoritative data and business outcomes
Governance applies to configured integrations and execution paths. A connection defines which operations are exposed; downstream access controls continue to apply.
01 / Define the operation
Make the API boundary
an explicit contract.
Define the operation's inputs, request mapping, expected response and exposed outputs. Keep the business-facing capability understandable even when the external service uses a different representation.
Associate the client and contract version with the application that uses it. Reuse that capability across execution graphs instead of reconstructing its meaning at every call site.
01
Describe the request
Identify the target operation and bind declared inputs to its path, parameters and payload. Make required values and expected types explicit.
02
Map the response
Define the returned fields and how they become typed application outputs. Keep transport details and business values distinguishable.
03
Declare its behavior
Record whether the capability reads, calculates, proposes, persists or changes an external system. That distinction shapes its controls.
EXPLICIT FIELD MAPPING · EXAMPLE
Give both sides
Give both sides
a known shape.
The workflow's business input can map to the service's field name without relying on implicit coercion or guessed payload structure.
Application valueAPI boundary
supplierId→ path {supplierId}
proposedAccountRef→ body bankAccountRef
expectedRevision→ body expectedRevision
updatedRevision← response revision
updateStatus← response status
INSPECT THE BOUNDARY
What does this API result actually establish?
Application input
expectedRevision is a required integer.
{
"supplierId": "SUP-204",
"proposedAccountRef": "acct_ref_6729",
"expectedRevision": 18
}
Input contract satisfied.
External response
HTTP 200 · confirmed destination-state example
{
"supplierId": "SUP-204",
"revision": 19,
"status": "applied"
}
revision → updatedRevision · integer
Confirmed in this example
The contract and the business result agree.
The declared request is valid. The destination's authoritative record confirms the intended update, and the response satisfies the exposed output contract.
- Invocation boundary
- authority, policy and approval checks satisfied.
- Next eligible action
- Expose the validated outputs and retain the effect evidence.
- Business effect
- Confirmed by matching destination evidence, not by the HTTP status alone.
Before publication
Review the definitions and bindings.
Check required inputs, field mappings, output types and the consuming workflow's expectations. Strict schema contracts expose incompatible definitions before publication.
At runtime
Validate the values that arrive.
A compatible definition does not guarantee every live payload is valid. Reject nonconforming values at the boundary and route the exception before downstream steps use them.
At the business boundary
Establish what the result means.
Valid JSON does not prove permission, freshness or a completed external effect. Keep those checks connected to the operation.
02 / Carry authority into the call
Authenticate the connection.
Authorize the business action.
A downstream service may use its own workload credential. The application still needs to preserve whose business authority initiated the operation and which resource, tenant and purpose apply.
Evaluate the caller, workload, delegation, resource scope and policy at the configured invocation boundary. Connection access alone does not grant permission for every operation that service can perform.
Integrated HITL + FIDO2
A request to an API can wait
for an accountable human
decision.
The HITL Inbox gives an authorized internal reviewer the proposal, evidence and facts before a protected write. Bind policy-required FIDO2 approval to that revision, then revalidate before the API call.
SUPPLIER WRITE · GOVERNED INVOCATION
-
01
Check caller and supplier scopeTenant, resource, purpose and delegated authority
-
02
Evaluate business facts and policyRecent changes, exposure and verification history
-
03
Obtain the required human decisionExact proposal + policy-required FIDO2 assurance
-
04
Revalidate and invoke the operationCurrent conditions at the protected effect boundary
Each step belongs to the same inspectable execution.
READ OPERATIONS HAVE GOVERNANCE TOO
API data keeps its access boundaries.
Use returned records and calculated facts with their source identity, permissions, classification and provenance in view. Eligibility checks determine what may inform an agent, policy or reviewer.
03 / Connect operations into business work
One agent tool.
An entire governed workflow.
A useful agent capability may involve several service calls, deterministic checks, a calculation, a human decision and an external update.
Compose that work in Frozion, with explicit contracts at each boundary. Include API operations and external MCP tools, with policy applied before and after MCP calls. Expose the complete workflow natively as an MCP tool, or invoke it over HTTPS, while preserving the controls inside it.
EXISTING AGENT REQUEST
“Process this supplier account change.”
Governed workflow
01 / READLoad current supplier state
Use the eligible API operation and preserve the returned record's context.
02 / EVALUATEValidate and calculate facts
Combine deterministic checks, verification results and Feature Store measures.
03 / DECIDEEnforce policy and human obligations
Apply nested conditions, scoped review and FIDO2 assurance where required.
04 / ACTInvoke and establish the effect
Recheck the intended write, invoke the API and retain the resulting evidence.
Asynchronous work
A response can mean
“accepted,” not “finished.”
Some services return a job reference or accept work for later completion. Define how the workflow follows status or correlates a callback under that service's contract.
Persist the wait state and validate the arriving event before continuation. A long-running workflow can outlast the original browser or agent request.
Uncertain effects
A timeout can leave
the outcome unresolved.
Use a stable Business Operation Identity across technical attempts. Apply destination idempotency where supported and reconcile authoritative state before repeating an ambiguous consequential write.
If the outcome remains unknown, keep it explicit and follow the configured escalation path. A response-contract error after dispatch also does not undo an effect that may already have occurred.
DISTINGUISH THE OUTCOMES
Give recovery the right starting point.
- Invalid request
- Hold before invocation; correct the contract or required input.
- Denied or unmet obligation
- Do not dispatch the protected operation until the applicable controls allow it.
- Accepted or pending
- Retain the operation reference and wait for the required outcome evidence.
- Response cannot be trusted
- Block dependent output use; separately establish whether the external effect occurred.
- Ambiguous effect
- Reconcile before another consequential attempt becomes eligible.
- Confirmed effect
- Retain the receipt and continue under the workflow's defined conditions.
External systems determine their own transaction and idempotency guarantees. Durable orchestration does not create universal exactly-once effects.
Explore durable recovery and reconciliation04 / Reuse with traceability
Inspect the call in context.
Evolve the client deliberately.
Follow the API invocation inside the execution that requested it. Connect client and contract versions, mapped inputs and outputs, authority, policy decisions, timing, attempts and reported effects.
Inspect the evidence your role permits without exposing credentials or unnecessary sensitive payload values.
From call record to execution evidence
Explain why it ran,
and what it accomplished.
A transport log can show that a request was sent. The execution graph connects that attempt to the proposal, calling actor, applicable policy, human decision and destination evidence.
Engineering can inspect contracts and failures. Operations can follow waits and retries. Security and audit can trace authority and the resulting business effect under their own scope.
Explore Behavior IntelligenceSupplier account update
- Capability
- Supplier client v3 · request/response contract v2
- Authority
- Tenant A · scoped supplier operation · current delegated context
- Policy & review
- Policy v4 · proposal revision 2 · required review and assurance recorded
- Operation & attempt
- OP-204 · attempt A1
- Validated result
- Supplier revision 19 · intended update confirmed
- Evidence
- Permitted request/response references and authoritative effect receipt
REUSABLE DEFINITION
Give teams a common capability.
Reuse the defined operation, contracts and mappings in multiple workflows. Preserve per-invocation context so reuse does not broaden the caller's authority.
VERSIONED CHANGE
Know which contract the work used.
See the client, adapter, capability and contract versions associated with the published application and execution evidence.
COMPATIBILITY REVIEW
See every workflow that uses it.
Open the client’s dependency view to find workflows and steps that use it. Review affected mappings and downstream expectations before publishing; compare workflow versions as part of the change review.
Active work stays interpretable.Preserve the versions needed to interpret in-flight state. A
new client definition does not silently migrate running work or
replace current authorization checks.
Fit into your integration architecture
Keep the gateway.
Connect the governed process.
Existing gateways, IAM, business services and telemetry can keep their responsibilities. Frozion adds application context around the API operation: contracts, authority, policy, people, durable state and evidence.
Use custom services and adapters for specialized requirements through explicit capability boundaries. API Client Builder is one part of the broader extensibility model.
Explore Developer ExtensibilityBefore you connect a service
Questions teams ask.
Yes. Through a supported integration, an existing agent
can invoke a Frozion workflow that uses API capabilities
alongside policies, data, human decisions and durable
execution. Define the workflow's entry contract and
completion behavior. The agent can retain its existing
language and framework.
Yes. The exposed tool can represent a complete governed
workflow. Inside it, compose multiple API operations,
calculations, Feature Store facts, per-step RBAC, nested
policy, HITL and FIDO2 where required. Define how the
caller tracks a process that may continue beyond the
original request.
They make declared shapes, required inputs, types and
mappings explicit, expose incompatible definitions before
publication and validate actual payloads at runtime. They
do not prove that a value is factually correct, that the
caller has authority or that an external write completed.
Those conditions are handled at their relevant boundaries.
No. A workload credential can authenticate the connection
while the application retains the initiating subject,
tenant, purpose, delegation and resource scope. Frozion
applies the configured business authorization and policy
checks; the destination continues to enforce its own
access controls.
Block dependent use of invalid response data and follow
the defined exception path. If the request was dispatched,
separately establish whether an external effect occurred.
A timeout alone is not proof of failure; consequential
ambiguous writes may require reconciliation before another
attempt is eligible.
Use the supported service contract to retain an operation
or job reference, follow status or correlate a completion
event. The workflow can persist its wait and validate the
relevant proposal, authority, event and business state
before resuming. An acceptance response is distinct from
evidence of completion.
Existing services, gateways, IAM and systems of record can
remain. Frozion connects supported operations to
application contracts, authority, workflow state and
evidence. Specialized integrations can use custom adapters
or services within the broader Developer Extensibility
model.
Frozion can expose any tool, workflow or agent built in the platform natively as an MCP tool or endpoint. Its workflows can also invoke external MCP endpoints, applying policy before and after the call. The Tool Call Resolver/Router presents internal tools, workflows and external MCP tools to the model, with multi-turn parameter population before invocation. Start with a protected operation and extend it visually into a durable workflow without coding.
Bring one API and the business action it enables
Connect the service.
Make the operation accountable.
We'll map the contracts, authority, human decisions
and outcome evidence your workflow needs.