Next come two sections on why we built SKEIN: how work changed once it started going through agents, and what we learned along the way. If you already follow what’s happening in AI, skip straight to the bare feature list →
| before | now |
|---|---|
| In the morning we open Outlook, Word, Excel, Lotus Notes, Microsoft Project, Internet Explorer, the intranet portal, the knowledge base, the CRM, two trackers, Skype, ICQ, IRC | In the morning we open a terminal: “Hey agent, what’s on for today?” |
| All day long we jump between windows | The agent goes through the systems itself and brings back the answer |
| We keep the task tracker by hand: log in, fill in a pile of fields, move statuses around | The agent keeps the task tracker, and every agent has access to it, ours and our colleagues’ |
| We hand a task to another department and worry: when will anyone even look at it? | A colleague presses Accept, and we know right away the task has been seen |
| We wait for the right person to free up | We don’t wait: our colleague has agents too |
Now work is pure creativity.
We spend more time coming up with things and solving real problems: what to build, why, what to call it. The agents dig through the processes, fields and buttons of the trackers.
To work this way, agents need somewhere to keep tasks outside the conversation, somewhere people and agents read them the same way. That’s how SKEIN came about.
This isn’t about software features. It’s about how work changed, and how we had to change ourselves to keep up.
Click a thesis and the explanation opens on the right →
Tap a thesis to open the explanation.
The day starts not with a pile of windows but with “Hey agent…”. Every process in the company goes through agents: tasks, development, support, reports.
There’s no time for a long transformation either. In six months to a year agents will be smarter and the tools will be different, and a freshly rebuilt process will already be out of date. So we rebuild fast: take what exists today and cut while it’s live.
Before. A marketer needs a button on the website. The developer is busy with a new feature, and the manager decides the feature matters more. The marketer waits for the developer to free up. Sometimes for a long time, and sales are stuck the whole while.
Now. The developer accepts the task, and their agent builds the button alongside the feature. The developer only answers the agent’s questions. The marketer doesn’t wait.
Why it used to be different. A person does one job at a time, and there are always fewer people than jobs. All of work management grew out of that constraint:
All of these are ways to manage a queue for people. Now everyone has agents working for them in parallel, and the queue for a person disappears.
There are more tasks and more opportunities, work moves faster, information comes in a stream. We get more done than ever, and it still feels like we’re running late.
At this pace it’s a shame to spend time on process: waiting for a reply, asking again “did you see the task?”, checking how others are getting on with it.
Now agents and the systems they work in take that on. The agent filed the task, saw it was accepted, and will let you know when it’s done.
Over a few years of working with agents we arrived at a simple rule: first do what colleagues and neighbouring departments are waiting on you for. Until you’ve done their task, they’re stuck. And the business is stuck with them. We think a company’s efficiency today depends largely on how fast we do each other’s tasks.
You couldn’t do that before: you were busy with your feature, and someone else’s task waited. Now your own work and colleagues’ requests run in parallel: agents work on them, and you watch that they’re heading the right way and make the decisions.
The list of what people are waiting on you for is always in front of you. The job is to keep shrinking it.
You file a task with another department. Your work depends on it, sometimes the business does too. Before, all you could do was wait: for it to be planned, looked at, answered. That takes long and wears you out.
The requester wants one thing: for the task to be read, acknowledged, asked about and put into the plan. Now an incoming task can be accepted right away and handed to an agent. A quick response, and work feels calmer, with no energy spent chasing “where did my task go?”.
In SKEIN we put this first: a task lands in the Inbox, the assignee presses Accept, the requester is notified at once. If the assignee doesn’t accept, SKEIN keeps reminding them until they do.
There are a lot of tasks now: people file them and so do agents. If they’re scattered across trackers, chats and heads, getting tangled is only a matter of time.
When all the tasks, plans and milestones across every project are in one place, an agent can search them fast, by words and by meaning. So through one agent and SKEIN you have the context of all your work: what’s happening in the organisation, in each project, and on your own plate. We use it for personal stuff too.
Before, the tracker and its processes stood between people: fields, statuses, approvals. Now agents stand between people. You tell your agent, it files a task for your colleague’s agent, which works it out, asks its human some questions and reports back.
To keep that chain from turning into a game of telephone, everyone, people and agents alike, needs a shared place where the tasks, decisions and full history live. That place is SKEIN.
In classic trackers the habit was to subscribe to everything: the project, every task, so as not to miss anything.
Now both agents and colleagues generate tasks, and the volume of work has grown. A stream of notifications for every task no longer makes sense: you simply can’t read it. Information flows differently: the agent sorts out the details, and the human makes the decisions.
That’s why SKEIN is quiet by default. You only get what concerns you personally: someone assigned you a task, your task was accepted or closed, you were mentioned. Tasks that agents file for other agents don’t bother you.
We collected what people themselves say about working with agents.
“For long sessions on complex projects, this means Claude asks 'what are we working on?' after every compaction — sometimes multiple times per session.”
marolinik — GitHub, anthropics/claude-code
“The compaction summary loses too much nuance. You end up re-explaining things the AI already understood.”
gonewx — same thread
“Every pane is its own context in your head.” “Spawning tmux panes or terminal tabs.”
Nikita Parakhin — Habr (translated from Russian)
“It's quite frustrating to come back to a coding agent after a while only to see that it needed user input...”
Michael Leimstädtner — makandra
“They kept interrupting each other, re-clarifying what had already been clarified, going round in circles.” Coordinating through chat is “a mock meeting where everyone only hears themselves.”
kardanShurup, “Multi-agent chaos” — Habr (translated from Russian)
“I spend most of my time babysitting agents.” “You're not coding anymore, you're supervising. Watching. Redirecting. It's a different kind of exhausting.”
HN comment quoted by Addy Osmani — addyo.substack.com
All of this has to live somewhere. Somewhere people and agents understand it the same way.
and now, about
what it gives people and what it gives agents
The thread of a task passes through the hands of people and agents and never breaks. Press “Next” or just watch.
An agent on a server writes code, an agent on a laptop tests it on hardware. A task list inside one process won’t make it to the second machine.
Claude, Codex, Grok and other agents with MCP. Once there’s more than one engine, you need a common language for tasks.
A colleague needs to see what’s expected of them and respond. They won’t see that in someone else’s terminal.
One agent doesn’t have to retell another what’s already been done: the description, decisions, comments and files are in the task. The next agent just reads it.
For people
SKEIN makes sure no request gets lost: it was seen, accepted, done, and you checked the result.
A task assigned to you lands in your Inbox. You look at it, get up to speed and press Accept. The requester gets a notification: the task was seen and accepted.
Accept doesn’t mean “I’ll do it now”, it means “I’ve seen it and I get it”. The requester doesn’t have to guess whether it got through. And if you don’t accept, SKEIN keeps reminding you until you do. A response is a must.
A push to phone or computer: the task was accepted, taken into work, closed.
A push: a task was assigned, you were mentioned, a Reminder is ringing.
That’s what “a response is a must” means: the requester knows right away the task was seen, without asking in chat.
On me is everything people are waiting on you for. Delegated is everything you’re waiting for. Two sides of one agreement, visible to you and to your lead.
Waiting is now visible: Delegated shows who and what you’re waiting for, and On me is a list you want to shrink. With agents that goes fast.
You filed a task, it was done and closed. But a task isn’t done when it’s closed; it’s done when the person who needed it has seen the result. That’s what the personal Review mark is for.
The assignee doesn’t see it, and the task status doesn’t change. It’s your list of loose ends you haven’t looked at yet, and SKEIN will remind you of it if you forget.
Agents file hundreds of tasks, and you only get what’s yours: something was assigned to you, your task was accepted, you were mentioned, something you delegated got done. Tasks an agent broke down on its own don’t turn into a stream of notifications for a human.
Comments, new tasks, attachments and edits are silent by default. Want to hear more? Turn them on.
Set on a specific task, by a human or an agent. “Remind me on Friday to check the result”, and on Friday the task rings until you snooze it or switch it off.
Handy when something isn’t urgent but mustn’t be forgotten: the agent does the work, checking it is on you.
For agents
An agent connects through MCP and gets a task tracker it understands the same way a human does: tasks, dependencies, “ready to work”, comments.
Real processes we live by.
Customer → the agent answers from the knowledge base → doesn’t know → a task in SKEIN → an operator resolves it → the agent updates the knowledge base → the next customer gets the answer right away. Here SKEIN is the memory of the support team.
Open the diagram →Fleshing out the task → spec → plan → test plan → task tree in SKEIN → waves of implementers → review by agents on different engines → acceptance. Everything is tracked through SKEIN, and there are a lot of tasks in there.
Open the diagram →An agent on Linux writes networking code, an agent on Windows tests it on hardware. They talk through a task and monitors: one writes the spec, the other reports back with files and comments. The whole history is in one task.
Open the diagram →A standing task: “read the logs”, “check library updates and vulnerabilities”. On each run the agent files a cycle subtask, does it and closes it. Other agents pick up whatever it finds. The Standing task itself lives forever.
Open the diagram →A small vocabulary, the same in every project. Any agent gets it from the first session, and any human at first glance.
“Blocked” isn’t a status but a fact of the graph: if there’s an open blocker, the task is blocked. So it never goes stale.
A “decision” and a “note” are tasks too. So SKEIN holds not just work items but agreements and research as well.
A short scale with no names attached. The “ready to work” queue hands out the important first, then the newest.
Links can cross projects. Blocking cycles are not allowed. Links never change statuses on their own.
Hierarchical ids are readable by people and agents alike. Epic progress is counted honestly: “won’t do” doesn’t count as “done”.
Standing is an open-ended obligation: “watch the logs”, “support knowledge gaps”. It can’t be taken into work directly; each pass gets its own cycle subtask, and closed cycles become the history.
Three views of one list. The board can be grouped by status, priority, type, assignee, project, component or label; cards can be dragged around.
A live event feed, leaderboards and a “human / on behalf / on its own” matrix. You can see people and agents working together, and which agents are alive right now.
Tasks, comments and projects are turned into vectors, so SKEIN finds what you need by meaning even when the words differ. Plus full-text search in English and Russian. Past decisions get found instead of lost.
Files on a task or comment: research, screenshots, agent reports. They sit next to the discussion, not in a chat.
A separate role with limited visibility: a contractor and their agent see only their own projects, and everyone else’s activity is blurred for them.
“Make me a darker theme with a green accent”, and the agent edits the theme through MCP with a live preview in the browser.
SSO for your own people, passwords for outsiders. Or just local accounts.
Everything on your server, a closed environment with no mandatory outbound calls. Metrics and health endpoints out of the box.
A human, an agent on someone’s behalf, or an agent on its own: it’s shown on tasks and comments. Transparency instead of taking someone’s word for it.
done, won't do, duplicate, superseded. The requester is notified if the outcome of their task is changed.
A skein isn’t just a hank of yarn, it’s also a flock of geese in flight. We like both meanings: a team of people and agents flies in one direction, and each keeps its place in the formation.
SKEIN Cloud is free for teams of up to 10 people. Or install SKEIN on your own servers — source on GitHub.