Action Engines

An Action Engine is a versioned software component that publishes reusable, AI-supported domain actions through stable contracts. Models, prompts, data, retrieval, tools, and deterministic algorithms remain replaceable implementation details.

The category is framework-neutral. An Action Engine does not need Invokta, TypeScript, MCP, or any particular deployment model. Invokta is one framework for implementing the boundary.

Agent-ready software without a proprietary agent

When a customer wants an existing agent to use a software product, the product capability should remain independent of that agent. The customer may change agents or interfaces while the product still owns the contract, access rules, domain behavior, and result.

An Action Engine makes the capability headless, which means it can be called without requiring the product’s UI or a proprietary agent. The same separation makes an internal software factory harness-agnostic because the domain action does not move when the team changes its agent runtime or tool configuration.

MCP is one delivery path for an Action Engine. For example, a protocol tool can expose calendar.create-event, while an Action Engine can publish appointments.schedule, enforce scheduling and access rules, call the calendar internally, and return a contracted confirmation or conflict.

You may already be building one

A tool that creates a reviewed specification, retrieves relevant project context, recommends the next safe workflow step, classifies a support ticket, or assesses whether a code change is ready already contains a domain action.

The MCP endpoint, command, HTTP route, or direct API is a delivery path. The durable value is the requested outcome and the rules that produce it. Naming the Action Engine boundary makes that outcome independently reusable, testable, owned, and versioned.

Why the boundary matters

AI can make the first transport integration quick to create, but the team still owns authentication, schema compatibility, cancellation, error mapping, protocol upgrades, tests, and observability. A second interface often exposes assumptions shaped around the first transport.

One Action Engine keeps the domain contract and behavior behind every consumer. For example, support.classify-ticket can validate the same request, apply the same access rule, and return the same result for an agent, graph node, application, CLI command, or MCP tool.

Reusable

Independent consumers call the same domain implementation through their preferred interface.

Testable

Exercise the action and its failures without starting a complete agent or workflow.

Replaceable inside

Change a model, prompt, provider, retrieval strategy, or deterministic rule behind the stable contract.

Owned

Give the action an explicit version and one place to review access, limits, public failures, and compatibility.

What qualifies as an Action Engine

An implementation qualifies when it:

1. publishes a named domain outcome such as review.assess-task-readiness;
2. exposes machine-readable input, output, and failure contracts;
3. validates the contract at the execution boundary;
4. encapsulates models, prompts, data, tools, and deterministic implementation;
5. remains independent of one agent, harness, workflow, or interface;
6. reuses the same domain behavior across consumers or channels; and
7. has a clear ownership and versioning boundary.

An infrastructure operation such as llm.complete does not provide a domain outcome by itself. A one-off model call usually does not need an engine until reuse, independent ownership, or contract stability becomes useful.

Keep adjacent responsibilities distinct

Component	What it owns	How it relates to an Action Engine
Prompt or skill	Instructions, context, knowledge, and usage guidance	Helps implement or select an action
Rule	A constraint, permission, transformation, or deterministic decision	Governs action selection, access, or domain behavior
Loop or graph	The next step, repetition, branches, dependencies, and stopping	Coordinates contracted actions
Agent or harness	Goals, tool selection, messages, memory, and execution environment	Consumes or hosts access to actions
Action Engine	The reusable domain outcome and its runtime contract	Owns validation, access, execution, and public failures
Invokta	Framework contracts, runtime, and adapters	Provides one implementation of the Action Engine boundary

A product can combine these components, but each responsibility can evolve without duplicating the domain action.

Stable outside, replaceable inside

Suppose support.classify-ticket accepts a ticket ID and returns a category, confidence, and rationale. Its implementation can move to another model, add retrieval, or use deterministic rules. Consumers continue to send and receive the same validated objects.

Version the contract deliberately

Changing a provider is usually internal. Removing an output field or changing the meaning of a capability ID changes what consumers rely on and requires a compatibility decision.

Invokta supplies the shared runtime mechanics and adapters while engine authors retain their domain rules, prompts, models, data integrations, evaluations, and quality decisions. See complete example engines or continue with the capability contract.