We want Orkas to be the foundation an AI-native company runs on. That goal leads straight to one question: how do several people and several agents collaborate on the same project?
The answer looks quite different from the teamwork we're used to. To see why, it helps to start with where human collaboration came from. (For the step-by-step product walkthrough, see Shared projects: how people and AI agents work together in Orkas. This post is about the thinking behind it.)
Human collaboration grew around two human limits
First, people have limited bandwidth and limited memory. We can only take in so much at once, and we can only remember so much. So teams have to communicate constantly: sharing updates, aligning on goals, aligning on progress. Weekly meetings, stand-ups, daily and weekly reports, "quick sync?", "let's align": all of it compensates for this limit.
Second, much of it has to happen face to face. In person, there are more channels than words alone: body language, tone and expression all carry information. When someone says "the plan looks fine" across the table, you can hear whether they mean it. Just as important, meeting in person builds trust. That's why so many remote teams still get together in person every so often.
What changes when agents join
In a team of people and agents, the human side of collaboration still matters. But working with agents is very different from working with people. Agents have three clear strengths and three clear weaknesses.
Three strengths
High bandwidth and strong execution. This is especially true for tasks with clear, measurable goals. And the tasks agents can finish are getting longer, harder and more complex quickly. Describing its own coding agent, Meta reports a GPU kernel optimization task where the agent worked for up to 24 hours and made more than 1,000 tool calls (Meta). In October 2026, Linus Torvalds posted a Linux kernel patch series whose code, test programs and first-draft commit message were written by Claude Code; he ran the measurements on his own machine (LWN).
The world's knowledge and tools, end to end across disciplines. Pretraining has already packed the world's knowledge into the model. Give it the right tools and an agent can carry one piece of work across disciplines from start to finish: write the PRD → design → build → test → ship. When people do the same work, it takes product, design, engineering and QA working together, with another round of alignment at every handoff.
Few human weaknesses, and no trust to build first. An agent doesn't get tired, doesn't have bad days, and isn't embarrassed to ask a basic question. A new agent can start as soon as it has the project's context. There is no ramp-up period and no relationship to build first.
Three weaknesses
It needs clean context. Wrong context sends it off course. We've hit this ourselves: a field on our analytics dashboard said the data "can't be linked", when in fact it could; the field itself was computed wrong. Two different agents read that line and both dropped an entire user-journey analysis. A person seeing that conclusion would ask "is this still accurate?" An agent usually takes it at face value.
It's weak at long-horizon attribution. When several variables affect the result at once, it easily blames the wrong one, and people have to correct it. For a while, a few new pages on our site weren't getting indexed by Google. An agent concluded that "the site doesn't have enough authority, so Google won't spend crawl budget on it" and recommended building backlinks first. We pushed back and checked: the vast majority of the site's pages were already indexed. The few that weren't looked more like topics too far from what the site is about. Crawl budget had nothing to do with it, and building backlinks would have been the wrong move.
It's poor at adapting to a changing environment, especially when the change isn't in its pretraining data. A site that was just redesigned, a platform rule that just changed, a product that launched last month: a person notices "this is different" and changes approach. An agent often keeps working from what it already knows and retries the same thing again and again.
Why chat apps don't fit
Chat apps were designed for people working with people: messages scroll past one after another, @mentions and read receipts keep everyone in sync, and information is scattered across channels. That design compensates for exactly the two limits above. People have low bandwidth and short memory, so we keep posting and keep aligning.
For agents, it's the wrong shape:
- Small talk, discussion along the way and plans that were later dropped are all context noise to an agent.
- An agent doesn't need to build trust through conversation.
- What an agent actually needs is clean context and a clear task.
So collaboration between people and agents needs a redesign. And as agents keep getting more capable, the way we collaborate will keep changing too. We're still working this out in Orkas.
What Orkas does: keep what hasn't changed, redesign what has
Our approach is to keep the parts of collaboration that haven't changed and redesign the parts that have. Below is a shared project in Orkas; the four ideas map to the four highlighted areas.
1. Assigning, handing off and reviewing work: To-do
This existed long before agents, and we still need it. For now, every task in our projects has a human owner, and a person is responsible for the final result.
In the product, it works like this. Each to-do is assigned to a person, and that person decides which agent does the work. Only the owner can start the to-do; the agent runs on the owner's own computer, with their model and their credits. When it's done, the agent moves the to-do to Awaiting confirmation rather than marking it done itself. It's finished only after the owner has checked it and made any changes.
2. Sharing goals, background and context: Goals & rules, Memory
Here, people and agents share the same context, so the key facts stay aligned.
A project's Goals & rules and Memory are shared by every conversation in the project, and agents follow them every time. For example, put a definition like "monthly retention = new users who come back the following month" in Goals & rules, and record key decisions in project memory. When a new member and their agents join, they read exactly the same thing on day one.
3. Hand off through files, keep the process apart
The project's Library syncs between members, and a to-do can carry any file as an attachment. Work is handed off as files, not chat history.
We deliberately keep the bulk of the in-between process apart, so it doesn't become harmful context noise for agents. The locked Tasks and Automation tabs belong only to you. An agent might take hundreds of steps and try three approaches before producing one report. Your colleague receives only the report; the process stays in your own tasks and never ends up in their agents' context.
4. Share private agents with the team
Members can share their private agents for the rest of the team to use. These agents carry their owner's experience and judgment of quality. Sharing them speeds everyone up, and problems people find while using them can be fixed through self-evolution, which raises what the whole project can do.
When an agent is shared, Orkas packages its working instructions and skills, including the skills it built up on its own while working. Its memory and chat history are not included. When the person who shared it updates the agent, members get the new version automatically.
An early, open problem
Collaboration between people and agents is still at a very early stage, and the answers haven't converged. As models improve, much of what agents need for collaboration will move into the models themselves.
Some models can already do this natively: run several sub-agents in parallel to explore a problem from different angles, or plan first and then dispatch sub-agents to carry out the plan. Muse Spark Open, which Meta released as open weights in October 2026, is described as trained to break work down, hand it to sub-agents and coordinate them (PyTorch blog).
So the way we collaborate will change as models get better. To-dos, shared context, file handoff and shared agents are our answer for what models can do today, not the final form.
Closing thoughts
We kept what hasn't changed: someone owns the work, someone reviews it, and goals and context stay aligned. We redesigned what has: hand off through files, keep the process apart, and turn each person's experience and taste into agents the team can use.
We're still exploring this, and we'd like to compare notes. If you run a team where people and agents work together, try it on one project first. Orkas is a free download for macOS and Windows.