Inistate

The business-process harness.

A new category for governed human-AI collaboration. Humans, AI, and hybrid actors executing against a single primitive — with one audit trail for all of them. It is what runs the one workflow your people, AI, and automations all work from.

See the proof → Read the architecture

Models are rented. The harness is owned.

Two ways to put AI to work.

A useful analogy is a robot designed to use existing tools and spaces. Enterprise AI should likewise work within defined forms, permissions, and review processes.

The harness gives AI an operational environment shared with human users: the same forms, state transitions, and audit structure. Connecting an agent still requires authentication, permissions, and workflow configuration.

That is the choice every AI procurement now faces, and it is the question to put to every vendor:

Does your AI operate inside your governance environment, or expect you to build a new one?

A category, not a feature.

When workflow rules live only in prompts or runtime-specific code, changing the model or agent can require rediscovering and retesting those rules.

Inistate makes a different commitment. We externalize workflows, states, forms, transitions, and audit trails into persistent schemas. Together with live entries and audit records, those schemas form the operational source of truth . Humans, AI, and hybrid actors all execute against them, through one primitive, with one audit shape.

We call this operational foundation the business-process harness.

What makes something a harness.

  1. 01

    A schema-as-contract

    The schema defines the allowed states, forms, and transitions. Actors submit data against that contract; entries hold current values, and history events record what happened.

  2. 02

    A unified action primitive

    Workflow execution follows State → Activity(Form) → State. Discovery and schema administration support that execution; they are not business-state transitions. Whether the actor is a human in a browser, an AI agent through MCP, or a hybrid sequence of both, the primitive is identical.

  3. 03

    A single audit substrate

    Every transition produces one history event with identical fields: by, on, changes, and an optional ai object. The audit shape does not vary by actor type. A shared structure makes audit records easier to query across actors.

  4. 04

    A discovery protocol

    Workspaces, modules, schemas, transitions, and tools are all discoverable through the MCP server. An authenticated AI can discover deployment context through the protocol, within its permissions.

  5. 05

    A confidence and intention recording layer

    AI-submitted transitions persist confidence scores. Below threshold, the system records an intention event with flagged: true and the AI must escalate to a human. Human review is part of the execution contract.

  6. 06

    A multi-actor governance model

    Activities are typed by who can perform them: human-only, AI-only, hybrid, or any-actor. Promoting a human activity to AI changes one field in the configuration. The process model, the form schema, and the audit are unchanged.

These six properties define the harness contract. The seven-demo proof reel pairs available product screenshots with written scenarios so you can inspect the supporting evidence.

The properties depend on each other.

The six properties reinforce each other. The schema defines the action contract; shared transitions and history support governance; discovery exposes the contract to agents.

The dependency graph: twelve layers from form-as-primitive at the foundation up to the consumer promise. The layers connect user-facing capabilities to shared execution and audit foundations.
"Describe it. Use it." / "Snap it. Track it." Run-by-text on a governed state machine MCP discovery and governed workflow execution User requests grounded in schemas and live records Schema-learning + schema-designing Model portability (workflow is the truth, model is swappable) Shared audit records supporting oversight Confidence gating + intention events Actor Parity (the principle) Single audit schema (one record shape for human/AI/hybrid) Single transition mechanism (State → Activity(Form) → State) Form-as-primitive

Evaluate the properties together. A shared audit structure is only useful if validation and governance remain consistent across the actions it records.

What the harness is not.

These product categories can overlap. The distinctions below explain what the harness requires beyond each individual capability.

Not

A workflow tool.

Why not

Workflow tooling defines processes. The harness adds an explicit requirement: human and AI actions share validation, transitions, and audit structure.

Not

An agent framework.

Why not

Agent frameworks embed operational intelligence inside prompts and runtimes. The harness externalizes it into persistent schemas that survive the agent.

Not

A low-code app builder.

Why not

Low-code app builders generate UI on top of stateful databases. The harness is a state machine with native AI execution and audit, with UI as one possible surface.

Not

A model orchestration layer.

Why not

Model orchestration layers route prompts between models. The harness is model-portable; the workflow is the truth, and the model is swappable.

See it executing.

The seven-demo proof reel connects these properties to concrete examples. Four examples include screenshots; three are written scenarios awaiting supporting captures.

01
Demo 1 of 7

Multi-Model Relay

User input

"go to LV 00003 and Approve it"

Audit history pane showing transitions performed by Claude Opus 4.5 and GPT-5.5 Thinking on the same Leave Application entry
Product screenshot · Select image to view at full size.

The history for Bob Wilson’s leave application LV 00003 shows Claude Opus 4.5 moving it to Submitted with confidence 95%, followed by GPT-5.5 Thinking approving it with confidence 98%. Both actions appear in the same history pane with model identity, reasoning, and confidence.

Architectural property

Actor Parity across model families.

What this shows

Two model families can act on the same leave workflow while retaining a shared audit format. This example demonstrates continuity across these models; each new model still needs evaluation.

→ See all seven demos
06
Demo 6 of 7

Module Creation from One Sentence

User input

"Create a module for leave application"

Haiku 4.5 invoking workflow design beside an Inistate leave entry in Draft with a claude-opus-4-5 audit event
Product screenshot · Select image to view at full size.

The conversation shows Haiku 4.5 receiving a request to create a leave application module and invoking the workflow design tool. The accompanying Inistate capture shows a created leave entry in Draft, with an AI audit event labeled claude-opus-4-5. These captures illustrate module design and entry creation; they do not establish that one model completed the entire lifecycle.

Architectural property

Schema design and entry creation through the harness.

What this shows

A short request can initiate module creation, and the resulting entry has an audit record. This capture does not verify elapsed time, production readiness, or an inference-cost benchmark.

→ See all seven demos
07
Demo 7 of 7

Multimodal Bootstrapping (BP Tracker from a Photograph)

User input

"Manage this"

A blood pressure monitor photo and the prompt Manage this beside a structured Blood Pressure Monitor entry
Product screenshot · Select image to view at full size.

The user supplies a photograph of a blood pressure monitor and the words “Manage this”. The conversation begins setting up a tracking module. The resulting entry shows a measurement date, systolic and diastolic readings, and pulse in a structured record.

Architectural property

Multimodal input translated into a structured operational record.

What this shows

A photograph can supply data for a tracking workflow. The image is interpreted by the model; the harness stores the resulting fields and workflow state.

→ See all seven demos

Patent references.

The references below identify the published application for the harness architecture and the provisional application for Actor Parity. A published application and a provisional filing are not themselves granted patents.

Patent references

The harness architecture is described in US Patent Application Publication 20230266946 A1 (August 2023) . The Actor Parity governance extensions are described in US Provisional Application #64/045,012 (filed April 21, 2026) .