One pair of hands
A chat window or a CLI runs while you watch it. Close the laptop and the work stops. Everything worth building needs more hands than you have, and more hours than you are awake.
Agent development, at scale
Many hands
on the loom.
Tecelon runs long-lived coding agents on machines you own. They clone, build, publish at a real address, and answer your customers — while you are asleep, in a meeting, or somewhere else entirely. Your CLI, your subscription, your machine.
Claude Code today, on your own subscription. Your GitHub. Your machine. Tecelon never sees your credentials.
The tool is not the bottleneck any more. You are.
It stops at your laptop
What comes out is a diff and a port on localhost. A domain, a certificate, an address you can send to a customer — that is still an afternoon of plumbing every single time.
Then the real work starts
A thing customers talk to needs a model, tools, a WhatsApp number, conversations, keys nobody should hold. That is a second stack, and nobody sells you both.
Give a worker a machine and a sentence.
A worker is not a chat about code, and not an API call wrapped in a web page. It is a real CLI session in a real container on a computer you own, acting as you on GitHub — for hours or weeks.
-
1
Connect a machine
One command on any computer with Docker — your laptop, a spare box, a server. It dials out to Tecelon; you open no ports. Share it with your team and a colleague with no Docker at all can start working.
docker run -d --name tecelon-host \ -v /var/run/docker.sock:/var/run/docker.sock \ -e REGISTRATION_TOKEN=… registry.tecelon.io/tecelon/host-agent -
2
Tell it what to build
In plain words. It works out which repositories it needs, clones them, and gets on with it. Watch the real terminal from your phone, answer a question from WhatsApp, or leave it alone — it keeps going.
-
3
It goes live by itself
What it builds runs as a container and gets its own https address in seconds — certificate and all. It pushes the code to a private repository of yours, with a Dockerfile and deploy notes, so it can leave for your own cloud whenever you want.
worker published https://shop-demo.apps.tecelon.io live · certificate issued · repo pushed
-
4
Go as deep as you would at your own desk
Nothing is hidden behind a friendly summary. Open the worker's actual terminal in the browser and type into it, or attach to the container from your own shell and work beside it. Steer it mid-thought, change how much it may do without asking, switch the model and effort it is thinking with — and it carries on from where it was.
you docker exec -it tecelon-worker-… bash the same container, the same session, your keyboard
-
5
And it can answer your customers
The same worker can stand up an AI agent, give it tools over MCP, test it, and put it on a channel under your brand — a web chat, WhatsApp, Telegram, whatever people already use to reach you. The thing it built and the thing that answers are one system, not two.
What people actually do with it
Three ideas before lunch
One worker per idea, each on its own branch, each ending in a link you can send to someone. Judge them by the thing itself rather than by a description of it, and throw two away without regret.
Put the work on the fast machine
Builds and test runs belong on the desktop under the desk or the server in the cupboard, not on a laptop on battery. The work happens there; your laptop is just the screen you watch it from.
Ten workers, not ten tabs
Each on its own project, its own container, its own branch — and all of them in one list that tells you which is stuck, which is waiting on you, and which has just finished.
No demo-to-production cliff
What a worker publishes is already a container, a private repo and deploy notes. Making it real is pointing it at your own cloud, not rebuilding it in a language the prototype never used.
Why not just Cursor, or the CLI?
Use them — they are excellent, and a worker is Claude Code. The difference is what happens around it.
An editor or CLI
A hosted agent service
Tecelon
Runs
While you watch
On their machines
For weeks, on yours
How many
One at a time
One task each
As many as your machines hold
Reach it from
Your desk
Their web app
A terminal in your pocket, or WhatsApp
What comes out
A diff
A pull request
A live address, a repo, a container
Your keys
On your disk
On their servers
Sealed, and never read by us
Leaving
n/a
Rewrite it
It was already a repo and a container
A worker is a CLI in a container on your machine, signed in to your own subscription through the provider's
own flow. We never see it, store it or relay it — and the day you leave, everything your workers built is
already in your GitHub and runs with docker run.
Bring your own everything.
A worker is a container with a CLI in it. That is a deliberately boring shape, and it is what keeps you free: the model, the subscription and the harness are yours to choose, not ours to sell you.
- Your subscription. Sign in to Claude on each machine through Anthropic's own flow — Tecelon never sees it, stores it or relays it.
- Or your key. Any endpoint that speaks Anthropic's API — DeepSeek today — drives the same worker, and the same key can back the agents you put on channels.
- Your model and effort, per worker. Opus for the hard one, something cheap for the errand, changed while it runs.
Claude Code is what runs in a worker today. Nothing above it is tied to one vendor — the container does not care which CLI it holds, and other harnesses are where this goes next.
Reach them however you already talk.
A channel is just where a conversation arrives. Tecelon treats them all the same way, so the agent your worker built does not care which one a customer turns up on.
- A web chat on your own page, with the key kept server-side
- WhatsApp, on your own Meta app and numbers
- Telegram bots, and more as they are added
- Your own workers, reachable from the same place — answer a question from your phone
Your standards, in every worker's hands.
Write down how you want things built — the stack you reach for, the bar an interface is held to, what "finished" means — and every worker reads it before writing a line. Not a prompt you paste again and again: a set of skills that travel with you, on every project, for everyone you work with.
- Mobile-first interfaces, designed empty and loading states, real contrast
- One container, one port, no state on disk — able to leave for any cloud
- A private repo, a Dockerfile and deploy notes, every time
Built for a team, not a laptop.
Invite someone and they are working in minutes: your shared machine, their own sign-in, their own GitHub. Keys are lent to an organisation rather than pasted around, and one organisation can never see another's agents, tools or keys.
- Shared machines, so a colleague needs no Docker of their own
- Keys sealed once and used by name, never typed into a command again
- Every brand, agent and channel owned by an organisation and walled from the rest
Weave something today.
Bring a computer with Docker and your Claude subscription. The first worker is running in about five minutes, and the first thing it publishes has a real address you can send to someone.