Human in control.

Set up agents and workflows yourself in one simple web interface, with no engineers or code required. Assign multi-step work from the web interface or a connected channel, wherever you are, then follow each run through its steps, approvals and results. You set the permissions; Kautuka keeps the work visible.

Runs on your computer
No online sign-up
Windows and Linux

Download for Windows

Kautuka.Installer.exe

Install on Linux

curl -fsSL https://github.com/devkrity/kautuka/releases/latest/download/kautuka-install-linux.sh | sudo bash

Linux install guide · or download the tarball

Open source, Apache-2.0 · Read the source on GitHub ↗ · See it ask first ↓

Kautuka approval request showing a proposed tool action and the decision controls

It asks. You decide.

One ordinary week, from a Monday request to a Tuesday yes.

Monday, 4:55 pm. You message your agent on Telegram: “Reply to Sarah’s quote request with our standard rates.”
4:56 pm. It reads your inbox and drafts the reply inside its own container. Drafting is set to On, so it just gets on with it.
4:57 pm. Sending email is set to Ask. Your phone buzzes: Kautuka wants to send the reply to Sarah. Approve or deny?
Illustration · the real message names the tool, mail_send.
You’re driving. You don’t answer. Overnight, the computer restarts for an update.
Tuesday, 7:40 am. Kautuka comes back up. The question is still waiting on your phone, and the email still hasn’t gone.
Illustration · the same request waits in the browser too.
7:41 am. You read it and tap approve. It sends. The run history shows the work: what it read, what it drafted, and who approved the send.
Illustration · the run history under the agent’s reply.

The agent does the work. You keep the decision. A restart never turns a “maybe” into a “yes”.

Four things you can count on.

See how a run reached its result

Follow the workflow’s path, inspect each step’s result and open the agent session behind it. A review stays pending through a restart.

Dashboard and traces ↗

Choose when an agent must ask

Set actions to Ask or mark workflow steps for review. Kautuka pauses there; approve, request changes or stop the run.

Approval behaviour and limits ↗

One setup for the whole team

The admin sets up model providers and the models the team can use. Team members can create agents and workflows; admins can share agents with others.

Execution has boundaries

Agents run in Gateway memory. Shell commands, skill scripts and local connectors run in their own rootless Podman containers with limited access to your computer. Model keys stay outside those containers.

How the security boundaries work ↗

Install once. Give your team access.

Install Kautuka on one computer and add team members. They can sign in through a browser on your network to create agents and workflows, without writing code.

Your models
Connect your own Ollama server for local models, or bring your API key for a cloud model provider. OpenRouter and other OpenAI-compatible APIs are supported. Not sure what to choose? Kautuka walks you through connecting a model. No Devkrity account needed.
Separate personal spaces
Share agents with your team while keeping each person’s files and memory separate.
A separate space for agent work
Kautuka keeps agent files in its own protected storage, separate from your usual files. Connect a cloud model or one running on your own computer. How it’s built ↗

Kautuka setup overview with provider, model, agent, and access configuration — Illustration · **Set it up once.** Choose models, set up agents, and add team members in one place.

Kautuka can serve your household, too.

Share useful agents while keeping each family member’s interactions and files private. Each agent’s owner chooses what it can access and which actions need approval; the run history shows what happened.

How shared access works ↗

What you can hand it.

Email

Built-in Google and Microsoft mail connectors list, search and read mail, handle attachments, draft and send. Set sending to Ask and nothing leaves without you.

Repeatable jobs

Turn a job you do every week into a workflow. Choose who does each step, add checks, and pick the steps that wait for your OK.

See how workflows work ↓

Chat where you already are

Give tasks and answer approvals on Telegram or Slack, or in the browser.

Providers, mail and channels ↗

The whole job, with you at the right step.

Some work is more than one task. Lay it out once on a canvas in your browser, and Kautuka runs it the same way every time.

Steps, in plain words. Each step is one of your agents, with an instruction written the way you’d brief a person. Click + under a step to add what happens next.
Product screenshot · A supplier invoice workflow on the canvas. Sample data.
Checks you set, not guesses. Send the work down a different path with a rule such as “If Amount is more than 500”. Every check has an “Otherwise”, and paths can join up again.
Product screenshot · A check reads like a sentence. Sample data.
Your OK where it matters. Tick “Check with me first” on the steps you want to see. The run waits with that step’s results in front of you: approve them, ask for changes with a note, or stop the run. Answer in the browser, on Telegram or on Slack.
Product screenshot · A run waiting for your OK at the step you marked. Sample data.
The path it took. Each run shows the path it took, marked on a drawing of every step.
Product screenshot · A ten-step run, with the path it took marked in green. Sample data.
A record you can inspect. A step journal shows what each step passed on. Each step links to its agent’s session, so you can inspect that agent’s work. If the computer restarts, a run waiting for you keeps waiting.
Product screenshot · A finished run: the step journal, what each step passed on, and the run’s activity. “Open agent activity” on any step opens that agent’s session, so you can see exactly what it did. Sample data.

Run it when you need it, or put it on a schedule. Workflow guide ↗

Little things, done right

The small stuff that makes it easy to live with.

Updates that undo themselves.

If an update fails, Kautuka goes back to the previous version by itself.

No answer means no.

Approvals wait for you by default. If the admin sets a time limit and nobody answers, the action is cancelled, not carried out.

Email starts on “ask me first”.

You loosen it only if you choose.

Commands are off until you say so.

Agents can’t run computer commands until you switch it on.

Only your chat counts.

Your Telegram bot only takes instructions from your own private chat.

Staff leave. Records stay.

The admin switches off their account and they’re signed out straight away, with nothing deleted.

See how it all works ↗

Built differently.

Question	Cloud agent platforms	Developer frameworks	Self-run assistants	Kautuka
Do you need to write code?	Sometimes	Yes	Usually some setup	No. Set up in the browser
Where does it run?	Provider’s cloud	In your application	On your hardware	Your own sandboxed environment on your Windows or Linux machine
Where do an agent’s commands and scripts run?	The platform decides	You build it	Varies	In a locked-down rootless Podman container
Can an agent run commands outside its sandbox?	The platform decides	You build it	Varies	No. With the sandbox off, it gets no shell or skills
Do local connectors get their own container?	Not applicable	You build it	Varies	Yes, by default
Where do agent files live?	Varies	Varies	Varies	In Kautuka’s protected storage, not your normal folders
Who approves risky actions?	Platform controls	You implement controls	Varies	You, on Telegram, Slack or the browser
Does a pending approval survive a restart?	Varies	You build it	Varies	Yes, including workflow reviews
Can a repeatable job wait for a person at a step you choose?	Varies	You build it	Varies	Yes. Tick “Check with me first” on any step
Who picks the next step in a workflow?	Varies	You build it	Varies	Rules you set on each step’s results, not the model
Can you read the record?	Platform’s format	You build logging	Varies	Yes, open format (Narad Protocol, MIT)

Columns describe typical products in each category as of October 2026. Individual products vary.

How it fits together on your computer

Agents run in Gateway memory. Shell commands, skill scripts and local connectors run in isolated containers. Anything set to Ask waits for your decision.

Your computer

Your browser

You open Kautuka in your browser at localhost:20229.

Other devices can reach it only if you allow your home network.

Windows only

Its own Linux distro in WSL 2

Your Windows drives aren’t mounted inside.
It can’t start Windows programs.

Kautuka appliance

The same on Windows and Linux.

Each service runs under its own system account.

Gateway

Control panel and API, on localhost by default.

Runs every agent and workflow, and makes the model calls.

Agents

Run in memory inside the Gateway, not in a container.

Ask for each action as a tool call.

No shell or file access of their own.

Approvals

Actions set to Ask wait for your answer.

Nothing runs until you approve.

Workflow steps you mark wait for your OK too.

Rootless Podman: where actions run

one per agent

Agent sandbox

Runs shell commands and skill scripts.
Non-root user, capabilities dropped, read-only system.
Only the agent’s own workspace can be written to.

Local connector

Runs in its own container by default.
Separate non-root user, capped memory and processes.
Stops when idle.

×2

Credentials service

Holds your keys in a separate service.

Model keys never enter a container.

A connector or skill gets only the keys it’s set up to use.

Run history

Kautuka stores the history in Narad Protocol’s open event format.

On Linux, the appliance runs directly on your system.

Remote connectors

Called by the Gateway over HTTPS.

Nothing installed on your computer.

Read this diagram as text

You open Kautuka in your browser on localhost. That connects you to the Gateway.
Agents run in memory inside the Gateway. When one needs to act, it asks for a tool call.
Actions set to Ask wait for your answer. Approved actions run in rootless Podman containers: the agent’s sandbox, or a local connector’s own container. Workflow steps marked “Check with me first” wait in the same place.
Your keys stay in a separate Credentials service, with model keys kept out of containers.
Kautuka stores run history using Narad Protocol’s open event format. Remote connectors are called over HTTPS.
On Windows, Kautuka runs in its own Linux distro in WSL 2, which can’t see your Windows drives. On Linux, it runs directly on your system.

Illustration · On Windows, everything inside the dashed line runs in Kautuka’s own Linux distro.

Straight answers.

Is this another claw?

No claws, just a band. A kautuka is the protective thread tied around the wrist at the start of something new. That’s the idea here: your agents get to work, and the thread keeps them safe and answerable to you.

Can agents reach the internet?

Yes. Containers have network access so agents can do online work. The container limits what they can touch on your machine, not where they can go online.

Where do my keys and passwords go?

Kautuka’s credentials service encrypts them and stores them separately. Model API keys never enter a container. A connector’s own sign-in goes only to that connector, when it needs it.

What does a cloud model see?

Whatever its request needs. To keep prompts on your machine, use Ollama locally.

Which tools get a container?

Shell commands, skill scripts and local connectors always run in one. Skills run in the agent’s sandbox, never on the host. Each connector that runs on your machine gets its own container by default. Remote connectors run on the provider’s side, not on your machine.

Where do agent files live?

In Kautuka’s protected storage, not in your normal folders. You decide whether each local connector can see the agent’s files.

Do I need to code to build a workflow?

No. You build it on a canvas in your browser: choose who does each step, say what they should do, and add checks. Build and edit on a computer. On a phone you can view a workflow and answer its reviews.

Does every step stop and wait for me?

No. Only the steps you mark “Check with me first” wait for your OK. Anything an agent does that’s set to Ask still asks, inside a workflow or not.

What if nobody answers a review?

The run keeps waiting, even through a restart. Reviews don’t wait forever, though. If one runs out of time unanswered, the run stops rather than carrying on.

Read the security model ↗

Open, all the way down.

Kautuka is open source under Apache-2.0; read the source on GitHub. Run records use Narad Protocol, MIT-licensed and on npm as @devkrity/narad, which we extracted from Kautuka. No Devkrity or Kautuka account or online registration is required. By default, operational telemetry stays on your appliance; Kautuka sends no usage data to Devkrity. Built by Devkrity in Australia.

Kautuka (कौतुक), Sanskrit for wonder, and the protective thread tied at the start of something new.

Current stable release

Let your agents do the work.
Your way.