Kabyn runtime

Define the operation. Kabyn keeps it running.

Kabyn runs the records, commands, workflows and approvals behind your business. Applications and AI clients use the same operation without rebuilding its rules or reliability infrastructure.

Request early accessAdapt a Process Pack

01 / Start with a Process Pack

A working process, not an empty template.

Each pack connects the records, commands and rules for a specific job. Install another pack and it uses the records already there.

Process PackJobs & Fulfilment
  • Business objectsCustomer, Job, Visit, Task
  • CommandsCreate job, schedule visit, complete work
  • EventsJob planned, visit completed, job closed
  • WorkflowsPlanning, delivery, approval and completion
  • AccessPermissions, policies and approvals
  • ViewsDataset Views and UI Surfaces
  • ConnectionsConfiguration, metadata and integrations
Quotes packJobs packTasks packOne Customer record

02 / How it fits

Every interface calls the same operation.

A chat client, a React application and an integration can all call completeJob. Kabyn applies the rule every time.

Interfaces

Chat and AICustom appsIntegrations

Access

MCPSDKAPI
KabynGoverned operational model
ObjectsCommandsEventsWorkflowsPermissionsApprovalsDataset ViewsUI SurfacesAudit

03 / Governed actions

Applications request named commands.

Interfaces call named commands. Kabyn checks the request, applies the rules and records the outcome before business state changes.

  1. Request

    completeJob

    An authorised user or application asks to complete a job.

  2. Check

    Rules and permission

    Kabyn checks required work, the caller's access and any approval.

  3. Change

    State transition

    The Job moves to Complete only when the command succeeds.

  4. Remember

    JobCompleted

    The event and audit record state what happened and who acted.

04 / When a process fails

Retry the work without repeating the action.

Real processes fail halfway through. A service becomes unavailable, a worker restarts or the same message arrives twice. Kabyn uses durable queues, safe retries and duplicate protection to keep the process moving without applying the same action again.

  1. 01Command received
  2. 02Duplicate check
  3. 03Permissions and rules
  4. 04Transactional change
  5. 05Event and audit record
  6. 06Durable message processing
  • The duplicate check protects the action from repeated requests.
  • The transaction keeps related changes consistent.
  • The queue retains work until it can be processed.
  • Recovery continues an interrupted process from a known state.
  • The audit record explains the outcome.

05 / Operational data

Store the record in Kabyn or connect the system that owns it.

A

Kabyn owns the record

Store jobs, projects, tasks, approvals and other operational state inside the shared model.

  • Rules and state in one definition
  • Validation on every command
  • Events for meaningful outcomes

B

An existing system owns it

Keep CRM or accounting data in its source system. Kabyn connects it to the operation through controlled integrations.

  • Named actions for every caller
  • The same permission checks
  • One process across connected systems

06 / UI Surfaces

Define each structured view once.

A UI Surface defines the layout and connects each control to a Kabyn Command.

IssueDetailissueId

Issue

Checkout fails on mobile
Status
In progress
Owner
Web team
Priority
High
Change status

MCP Apps can show a UI Surface inside an external AI conversation. A web application can show the same definition elsewhere. Kabyn owns the definition, so both stay in step.

07 / Before anything changes

Kabyn checks every command before it changes business state.

Permission

Can this person or system take the action?

Rules

Is the request valid for the current state?

Approval

Does a person need to decide?

Audit

Can the business explain what happened?

The durable operational layer

Change the interface. Keep the operation.

Request early access