Your users already chose their agent.Make your product work with it.
Your product already knows how the work should be done.Invokta packages that knowledge into actions any agent can invoke.
Three different callers invoke one Action Engine, which owns the capability and returns the same validated result to all of them. Showing appointments.schedule on clinic-engine, called by Claude, ChatGPT, Hermes.
Whichever assistant the patient brings, the clinic booking policy runs once, inside the action.
Build your own harness, or make your product invokable?
Every product is about to build its own agent, and almost nothing in that stack is its business. The other path: the harnesses your customers already use invoke the one part only your product knows how to do.
the only part that is yours
Months of infrastructure that is not your business, to end up competing with Claude and ChatGPT for the user's attention.
Request a refund for the sneakers that arrived wrong.
Done: approved under the exchange policy. $249 back within 3 days.
From raw tools to trusted outcomes
An MCP tool exposes one operation. An Invokta Action Engine ships the whole job: the order things run in, who is allowed to call it, and what a correct result has to contain.
Outcomes, not primitives
Publish engineering.prepare-implementation, not six raw tools the agent has to figure out how to combine.
Learn moreOne execution path
Every adapter calls engine.invoke, so validation, authorization, and error handling never fork per entry point.
Learn moreInvocable by any agentNew
One action, reachable over MCP, the CLI, HTTP, or a direct call. The consumer changes; the behavior doesn't.
Learn more
One capability, every entry point
The capability ID belongs to the engine map. The capability carries the contract and implementation that every entry point reuses.
import { createEngine, defineCapability } from "@invokta/core";import { z } from "zod"; const createWelcomeMessage = defineCapability({ title: "Create a welcome message", description: "Creates a short welcome message for a new team member.", input: z.object({ name: z.string().trim().min(1) }), output: z.object({ message: z.string().min(1) }), access: "authenticated", async run({ input }) { return { message: `Welcome, ${input.name}!` }; },}); export const engine = createEngine({ name: "hello-engine", version: "0.1.0", capabilities: { "onboarding.create-welcome-message": createWelcomeMessage, },});{ "message": "Welcome, Ada!"}Output validated against contract
Domain actions for every company area
Each of these teams has a process that gets re-taught to every new agent. Here is what it looks like published as an action instead.
Content and creative
Edit videos and produce social carousels through branded, provider-backed capabilities instead of rebuilding the creative process in every agent.
ExploreEngineering
Turn a ticket into implementation-ready work using repository context, architecture, design, risks, acceptance criteria, and a test strategy.
ExploreMarketing
Turn a product launch into an on-brand campaign grounded in positioning, audience research, evidence, and channel constraints.
ExploreSales
Generate account-specific proposals from CRM context while preserving the approved template, visual identity, pricing, and claims.
ExploreHealthcare operations
List valid appointment slots and schedule a patient through clinic policy and an authorized Google Calendar integration.
ExplorePeople and recruiting
Apply a reviewable job rubric, record screening evidence in the recruiting system, and notify the hiring team when human review is warranted.
Explore
The agent decides when. The engine decides how
Validation, authorization, cancellation, and error mapping happen once, inside the engine, before any caller sees a result.
Contract enforced at runtime
Input and output are validated on every call. A capability declares its schemas alongside its implementation, so a malformed request is rejected before the engine runs and an out-of-contract result never reaches a consumer.
See the contractOne pipeline, four adapters
Every adapter calls engine.invoke. Application code, the CLI, MCP stdio, and stateless MCP Streamable HTTP all resolve to the same execution path, so behavior does not fork per delivery surface.
See the contractAuthorization stays in the domain
Access rules are evaluated by your engine. Each capability carries an explicit access rule, and domain policy runs inside the invocation boundary rather than being re-implemented inside every agent that calls it.
See the contractPredictable failures
Cancellation and errors follow one taxonomy. Aborted invocations and failures map to a documented set of error types, so consumers can branch on a stable shape instead of parsing adapter-specific messages.
See the contract
Your customer owns the agent. You own the capability
Agents and models will change. The domain actions your product publishes should not have to be rebuilt every time they do. MCP, CLI, and HTTP are only the delivery paths.
- Claude
- ChatGPT
- Hermes
- CLI
- Application
- Providers
- Scripts
- Templates
- Data
- Rules
Don't build another agent. Make your product invokable.
Define one capability with its input, output, and access rule. Build the task once; invoke it from code, the CLI, and MCP.