Skip to main content

Developers · Agents

AI agents in Kinetic workflows

AI agents start and track work in Kinetic today, through the MCP server or the Core REST API. The workflow attached to each request runs its defined steps, whoever started it. Native agent work exchange, where a workflow assigns a step to an agent the way it would to a person, is in development.

Join early access Developer hub

Available today Agents create and read submissions through the MCP server or the Core REST API, under their own user's permissions. MCP server

Today Available

How agents work with Kinetic now

To Kinetic, an agent is a client with its own user account. It starts work and checks on it through the same endpoints any integration uses, and the workflow it triggers runs the same steps every time.

  • Start work through MCP

    An agent that supports MCP connects to the Kinetic MCP server as its own Kinetic user and creates a submission. The workflow attached to that form starts, as it would for a person.

    MCP server

  • Start and track work over REST

    Any agent framework can POST to /kapps/{kappSlug}/forms/{formSlug}/submissions, then GET /submissions/{submissionId} for state and values.

    Submission Create (opens in a new tab)

  • Call a workflow and get an answer

    A WebAPI runs a workflow from an inbound request and returns the result, for agent tools that need an answer in the same call.

    WebAPIs (opens in a new tab)

  • Use AI as a workflow step

    A workflow calls the model you choose through a Connection or a handler to classify, extract or summarize, then continues on fixed steps.

    Connections and Operations (opens in a new tab)

Example: an agent tool that opens a request

Two functions an agent framework can register as tools. The first submits an access request form; the second reads its state. Approvals and provisioning happen in the workflow attached to the form. An agent that supports MCP can skip this wrapper and use the MCP server's submissions tool.

The Kapp slug services, form slug access-request and field names are examples; use your own.

Python · agent tool using the Core REST API 
# A tool an agent can call today: open a request in Kinetic# and return its ID. Uses the Core REST API with an integration user.import os, requests BASE = "https://<your-space-url>/app/api/v1"AUTH = (os.environ["KINETIC_USER"], os.environ["KINETIC_PASSWORD"]) def open_access_request(employee: str, system: str, reason: str) -> str:    resp = requests.post(        f"{BASE}/kapps/services/forms/access-request/submissions",        params={"completed": "true"},        json={"values": {"Employee": employee, "System": system, "Reason": reason}},        auth=AUTH,        timeout=30,    )    resp.raise_for_status()    return resp.json()["submission"]["id"] def request_status(submission_id: str) -> dict:    resp = requests.get(        f"{BASE}/submissions/{submission_id}",        params={"include": "values,details"},        auth=AUTH,        timeout=30,    )    resp.raise_for_status()    sub = resp.json()["submission"]    return {"state": sub["coreState"], "values": sub["values"]}

Tested on version: pending verification

Direction In development

Agents as assignees in a workflow

Today an agent starts a request and checks on it. Native work exchange covers the other direction: a running workflow hands a step to an agent, the agent does it, and the work moves on with one status that people and agents both see.

  • Agents pick up work

    A workflow step can be assigned to an agent the way it is assigned to a person or team, and the agent completes it.

  • People and agents hand off

    Work moves between people, agents and systems inside one workflow, so everyone sees the same status.

  • The process stays fixed

    The workflow decides the order of steps. Agents do the steps they are given; they do not redesign the process while it runs.

Everything in this section is in development, and we do not publish dates for it. It builds on pieces that ship today: forms, workflows, security policies, the REST API and the MCP server.

Where to go next

Questions about agents

Answered by Kinetic Data. Last updated .

  • Can my agents work with Kinetic today?

    Yes. An agent that supports MCP uses the Kinetic MCP server; any other agent uses the Core REST API or a WebAPI. Either way, give each agent its own Kinetic user so security policies decide what it can do.

  • What is native agent work exchange?

    Workflow steps assigned to agents the way they are assigned to people or teams, picked up and completed without custom API code for each process. It is in development, and we do not publish dates for it.

  • How is this different from the MCP server?

    The MCP server is available now. Through it an agent can build forms and workflows, create records and start workflows, within its user's permissions. Native work exchange adds the other direction: a running workflow handing a step to an agent and waiting for the result.

  • What does early access involve?

    Working sessions with our product team. You bring a process where agents and people share work; we show how it runs on Kinetic today and review the in-development work against it before it ships.

Join early access for native agent work

Bring a process where agents and people need to share work. We show how it runs on Kinetic today and walk through the in-development work with our product team.

Join early access