Kylon for AI workflow automation

Workflow automation that reads the case before it acts.

Kylon is a company harness where agents join your team, understand your business context, and execute real work across the tools you already use.

Get started

The product, running

One question in a room, and the work comes back in it

This is the scene the page is arguing for. Someone asks in the room the work already lives in, the agent says which sources it read, and the result lands in the same conversation: a report, updated records and an email that is still a draft. Nothing changes until a person approves it.

The Kylon interface, rendered from the product's own stylesheet. Companies, people and figures are invented.

Three flows teams put an agent on first

Each one starts as a question in a room. When it should repeat, the same work is saved as a workflow on a schedule, a webhook or a record change, and every run keeps its history.

01

Research to brief

An account, a market or a competitor is named in the room. The agent reads the sources, the records you already keep and the thread above, then writes the brief where the team will discuss it.

You read the brief before anyone acts on it.

02

Lead signal to reviewed outreach

A form arrives or a record changes. The agent researches the company, writes the CRM note for that account and prepares the reply in the voice you use, through the mailbox you connected.

The email waits as a draft. A person sends it, or does not.

03

Recurring report to the room

A scheduled workflow pulls the same four sources, writes the summary against last period, and posts it in the room where the numbers are argued about instead of a folder nobody opens.

Anything it could not verify is named in the post, not estimated.

Chatbot, rule, or process

A process is not a longer answer. It branches, and it stops.

Vendors keep shipping the same idea under new names: Stonly's process agents follow the team's SOPs, OpenAI's Data agent acts on what it finds once you approve, Quickbase's Pave publishes a described process as a workflow, and Teradata's Tera pairs governed context with execution. In Kylon the same shape is four parts of the workspace.

Skills: the procedure you already wrote

The team's guide is a skill or a room guideline, read by every agent. Change the guide and the run changes.

Room context: branch on the case

The agent reads the thread, the records and the granted accounts before it picks a path, and names what it read.

Approval: stop where judgement starts

The refund calculated, the record change proposed, the reply unsent. Each waits for a person to release it.

Workflows: run it again, with a record

Save the work on a schedule, a webhook or a record change. Every run keeps its history next to the request.

Before it touches anything

The model got better at acting. The controls are a separate decision.

Frontier models are now described as doing the work rather than describing it: filling in forms, updating customer records, researching and drafting documents. OpenAI says so about GPT-6 Astra, and that is a capability claim about a model, not a statement about your systems. The questions below are the ones a team still has to answer, whichever model is underneath, and in Kylon each is a setting in the workspace rather than a sentence in a prompt.

OpenAI's GPT-6 Astra announcement, checked 16 September 2026

The decision
What you set
Where you see it
Which tools can it see
The rooms it belongs to and the connections it was granted, one account at a time
The agent names its sources in the reply, and a grant can be revoked on its own
What it may prepare on its own
Reading, research, summaries and drafts run without asking
The draft sits in the thread, addressed and written, with nothing sent
What waits for a person
Outbound messages and record changes stop as a draft or an approval card
The evidence and the proposed change sit in the same conversation as the approve control
What is recorded
Work happens in a thread, and repeated work is saved as a workflow
Run history for each execution, next to the request that started it
How you stop it
Pause the workflow, or take back the connection the step depends on
The run stops at its next step, and nothing it already drafted was sent

Kylon does not claim support for any particular frontier model on this page. These controls are properties of the workspace and hold for every agent in it.

The work you want automated
What a rule does
What an agent does
A lead fills in the form
The fields are copied into the CRM and the same template goes out to everyone
It researches the company, writes the CRM note for this account and drafts a reply a person sends, or does not
The weekly report is due
The same spreadsheet is rebuilt from the same four tools, by hand or by a scheduled export
A scheduled workflow pulls the four sources, writes the summary, and posts it in the room where the team already discusses it
A record changes in the tracker
The trigger fires the action it was configured with, whatever the record says
It reads what actually changed and decides what this case needs, inside the permissions you set
Something the flow never anticipated
The run fails, or completes the wrong step quietly
It says so in the room and leaves the decision to a person

What an agent needs before it can automate anything

  • The thread. It reads the room the work is already discussed in, not a form you fill in first.
  • The records. Trackers and tables live in the workspace, so the agent reads and writes them without an export.
  • The tools. 3,000+ services connect natively, from Gmail and Slack to Salesforce, HubSpot, Jira and GitHub.
  • Memory. Last month's decision is still there, so nothing has to be re-explained each run.
  • Permissions. Agents only see and touch what you allow, and sensitive actions wait for approval.

Where the result goes

CRM
Salesforce · HubSpot · Pipedrive · Close · Dynamics 365
Tasks
Linear · Jira · Asana · Trello · ClickUp · monday.com
Docs
Notion · Google Docs · Google Sheets · Confluence
Comms
Slack · Gmail · Outlook · Microsoft Teams

How it works

  1. 01

    Read. Ask for the work in the room it already lives in. The agent reads the thread, the records in the workspace and the accounts it was granted, and names each source in its reply.

  2. 02

    Draft. It comes back with the work itself: the summary written, the record change proposed with the evidence behind it, the email addressed and still unsent.

  3. 03

    Approve. A person releases anything that leaves the room or changes a record. Until then nothing is sent and nothing is saved.

  4. 04

    Run. When the same work should repeat, keep it as a workflow on a schedule, a webhook or a record change, and read what happened in its run history.

What Kylon does not do

This is not a canvas of boxes and arrows, and it is not the better tool for every job. If the same trigger should always run the same steps, a rule-based automation is simpler and more predictable than an agent. Kylon is for the part where the steps depend on the case and someone has to look at the result.

Questions people ask

How is this different from Zapier, Make or n8n?
Those tools run a sequence you define in advance: a trigger, then the same actions every time. A Kylon agent reads the context of the specific case first, decides what that case needs, and hands the result back for review. Keep the automations that already work. Put an agent on the part that needs someone to read the situation before acting.
Does it run on a schedule, or only when someone asks?
Both. A person can ask in the room, and a workflow can start on a schedule, a webhook or a record change. Runs keep their history, so you can see what happened and why.
Do I have to build the workflow before I get anything out of it?
No. You start by asking for the work itself. When a piece of it should repeat, you save that as a workflow. There is no build phase to get through first, and no code or configuration files.
What stops an agent doing something it should not?
Scoped permissions: agents only see and touch what you allow. Sensitive actions wait for approval before they execute, and admins, members and agents each get distinct permission tiers.
What does one run look like from start to finish?
Four steps, and the third one is a person. The agent reads the case and names the sources it used, drafts the change or the message, stops for approval on anything that leaves the room or edits a record, then repeats the same work as a saved workflow when it should run again. Long running context, tool use and subagents are vendor vocabulary for the first two steps. The approval and the run history are the parts that decide whether a team can put the automation near production systems.
Our analytics tool already answers the question and can act on it. Where does this sit?
Ask it there, finish the work here. A connected analysis tool is better at the query, and what it hands back is a finding with a suggested next step. The step after that is the job: the note written on the account, the record change proposed with the evidence behind it, the message addressed and still unsent, all in the thread where the team will discuss them and released by a person. Kylon is not an analytics tool and does not connect to a warehouse; it reads the records in the workspace and the accounts you connected.
Newer models can operate software themselves. Does that replace this?
It changes what the model can do, not what your workspace allows. A model that can fill in a form still needs an account to act through, a boundary around what it may reach, a person on the actions that leave the building, and a record of what ran. Kylon holds those four things, so a better model makes the same workflow better without widening its access.

Keep reading

Most work is not a fixed sequence.

Automate the part that repeats, and let an agent handle the part that depends on the case. A person still approves what leaves the room.

Get started