Agentic AI

IntegraHive is built for agent operations, and the governance layer was built first. The controls that bound what an automated actor may do — tenant-scoped execution, approval policy, a catalogue of governed actions, durable state and auditable outcomes — are implemented. The model-assisted capability is a separate subsystem. Connecting a model-driven planner to the governed execution loop is roadmap work, and this page says so everywhere it is relevant.

Current status

Read this table before anything else on the page. Nothing below quietly upgrades it.

Layer	Status
Governed deterministic operations	Implemented. Present in the application. Runtime operation in the deployed environment has not been independently verified.
AI-assisted mapping, onboarding, and retrieval-grounded context	In development. Integrated into the application. Whether it works end to end in the deployed environment has not been verified, so it is not offered as something to try.
Model-driven planning inside the governed execution loop	Roadmap. Not implemented.

The governed execution loop is not model-driven. Its planners are deterministic. Nothing on this page should be read as describing an AI system that decides what executes.

Why the boundary exists before the model

A planner that proposes actions and a system that authorises them are different kinds of component, and they fail in different ways. A probabilistic planner can propose something plausible and wrong. That is not a defect to be trained away; it is a property of the class of system. The useful question is not "how do we stop it proposing the wrong thing" but "what happens when it does".

If authority to act lives inside the planner, the answer depends on the planner's judgement, which is the thing in question. If authority lives outside it, the answer is a property of the system and can be stated in advance.

So the boundary is the design: a proposal is not a permission. Everything that decides whether something may execute is deterministic, inspectable, and independent of whatever produced the proposal. Building that first means a model planner can later be connected to a loop that already refuses what it should refuse — rather than the loop being retrofitted around a planner already in production.

The governed execution loop, as implemented

A business event enters the loop. A deterministic planner produces candidate actions. Each candidate is evaluated against policy, which either permits it, holds it for human approval, or refuses it. A permitted action runs through a governed action from a fixed catalogue, scoped to a single tenant. The outcome is recorded as evidence.

Bounded autonomy

Actions carry a risk tier. The highest tier is a permanent barrier: it can never execute automatically, and no policy or approval can lower that bar. Below it, each tenant has a ceiling, and an action above the ceiling is held rather than run.

A tenant's policy may only ever restrict. The configuration path rejects a tenant-level setting that would grant more autonomy than the defaults allow, so tightening is always possible and loosening is not.

Approval that actually holds

When policy holds an action, execution stops and a durable record of the pending decision is written. It is not a warning that execution proceeds past.

Approval is narrow by construction. It is checked after the hard refusals and after the tenant ceiling, which means the only transition an approval can cause is "held" to "permitted". It cannot revive a refused action or widen a tenant restriction — those have already been decided by the time approval is considered.

An approval is also bound to the specific action it was granted for. The check compares the action about to run against what was approved, deriving that comparison from the action itself rather than from the approval record — so an approval for one set of parameters cannot authorise a different call.

Tenant-scoped tools

Governed actions execute inside a tenant-scoped database session. The governed execution path uses the platform's database-enforced tenant-isolation controls — the boundary is in the database, not in a filter the calling code is trusted to remember. Those controls are implemented; clean end-to-end evidence remains in progress, and tenant isolation describes exactly what has and has not been demonstrated. Nothing here should be read as a proven or guaranteed isolation claim.

The tenant identity is validated before any work begins and is rejected if malformed. The narrow cross-tenant path used for administrative reads takes no tenant input at all and runs read-only, so it cannot be steered into writing another tenant's data.

How enforcement errors resolve

Identified enforcement failures in the governed action path resolve to a hold or a denial rather than execution. If policy evaluation raises an error, the action is refused. If the action catalogue cannot be consulted, the action is held for approval rather than allowed through.

This is a statement about the errors that are identified and handled on that path. It is not a claim that every possible infrastructure, application, or future model failure has been shown to behave this way — that would require evidence which does not exist.

Durable state and retries

Work is durable rather than held in memory, so a restart does not lose an in-flight case or silently re-run a completed one. Retries are explicit, and recovery is a defined state rather than an exception.

Side-effect uncertainty, stated rather than inferred

When an action fails, the system records whether the effect definitely did not happen, definitely did, or may have. That third state is the honest one and most systems do not model it: a call that times out after dispatch genuinely does not know whether the far side acted.

The distinction is carried explicitly from the point of failure rather than guessed at afterwards, because "retry safely" and "a human must look at this" are different instructions, and inferring the wrong one causes either a duplicate action or an ignored one.

Evidence

Each policy decision and each execution step is recorded — what was proposed, what policy decided, what ran, and what resulted. The purpose is reconstruction: what happened, in what order, under whose approval.

AI-assisted capability — integrated, not verified

Separately from the governed loop, the platform integrates model-assisted workflows for mapping and partner onboarding, with retrieval-grounded context drawn from integration-domain reference material.

It is present in the application and reachable through it. Whether it works end to end in the deployed environment has not been demonstrated. That is the whole of the claim: not that it works, and not that it fails — neither has been established, so it is listed as in-development rather than offered as something to try.

That symmetry is deliberate. Reporting an untested capability as broken is the same error as reporting it as working; it is simply the flattering direction of it, and it is still a claim nobody checked.

It is also, importantly, not connected to the governed execution loop. It assists a person authoring a mapping or onboarding a partner. It does not propose actions into the loop, and the loop does not consult it.

Roadmap: connecting model-driven planning

Roadmap — not implemented. The intended next step is to allow a model-driven planner to propose candidate actions into the existing control layer, entering at the same policy and approval gate the deterministic planners already pass through, with no new authority.

The property that makes this tractable is that nothing about the gate has to change: it already refuses, holds, scopes, records, and fails closed regardless of what produced the proposal. A model planner would be a new source of candidates, not a new path to execution.

Failure modes this design has to survive

An honest account of what goes wrong, and which of these the current controls address.

Hallucinated actions. A planner proposes something plausible and wrong. Addressed structurally: proposals carry no authority. An action outside the catalogue cannot be invoked at all, and one inside it is still evaluated against policy.

Excessive permissions. An automated actor accumulates authority beyond its task. Addressed: the action catalogue is fixed, the risk ladder has a permanent ceiling, and a tenant's policy can only narrow it further.

Cross-tenant contamination. Context or data from one tenant reaches another. Addressed: execution is scoped by a database-enforced tenant boundary, and the cross-tenant read path takes no tenant input and cannot write.

Retry duplication. A retried action repeats an effect that already happened. Partially addressed: the system distinguishes "did not happen" from "may have happened" and does not treat the uncertain case as safe to retry. Whether a given downstream action is idempotent is a property of that action.

Unverifiable outcomes. The system reports success it cannot substantiate. Addressed in principle: outcomes are recorded as evidence, and an uncertain side effect is recorded as uncertain rather than rounded to success. This is the same discipline described in evidence.

Prompt injection. Untrusted content instructs a model to act outside its task. This needs stating in two halves, because a single platform-wide answer would be wrong.

Inside the governed execution path: execution authority does not consume model output today, so there is no path from injected text to a governed action. That is a property of the current separation, not a defence that has been built.

Inside the AI-assisted workflows: those workflows do process model context, so they carry model-input risk like any such system. They are not immune to prompt injection, they require their own input and content defences, and nothing on this page should be read as claiming otherwise.

And when the two are connected: introducing a model planner into the governed path creates a new trust boundary that would require explicit adversarial testing and its own mitigations before it could be relied on. The existing controls — catalogue, risk ceiling, tenant scope, approval — would constrain a compromised planner's blast radius, but constraining blast radius is not the same as preventing the injection.

Stale context. A planner reasons from data that has since changed. Not addressed as a distinct control today. The approval binding limits the blast radius — an approval authorises specific parameters, not a standing permission — but detecting that context has gone stale between proposal and execution is open work.

What is deliberately not claimed

The platform does not repair production faults unattended, does not recover from them without a person, and does not learn from its own operation. There is no labelled evaluation set for planner quality, so no accuracy figure is claimed. And nothing here should be read as saying a model decides what executes — none does.

Tenant isolation — the database-enforced boundary governed actions execute inside
Governance — schema-drift policy and the deterministic controls around ingestion
Evidence — what is actually proven, and the difference between a control working and evidence that it works
Architecture — where these layers sit