We want to build a company operating system: a place where work happens, context accumulates, and humans and agents work together across every function.
The first milestone is a digital employee that feels like a great colleague. It learns quickly, works naturally with people, and can be trusted with consequential work.
Today's agents can already read documents, operate software, write code, reconcile data, and run complex processes. The harder problem is turning that capability into dependable work. These are the problems we think matter most.
Memory retrieval does not scale into learning.
When a human gives an agent feedback, the system must decide how the agent should be taught. Should the feedback become a memory? Should it update the agent's instructions? Should we write a new skill or piece of code and teach the agent when to use it? Should the information live in a vendor database? Or has the work become distinct enough to warrant a new specialist agent?
These are different interventions with different costs and failure modes. Treating all feedback as memory creates an ever-growing retrieval problem. Treating it all as instructions makes the agent incoherent. Turning everything into code makes the system brittle. The hard problem is choosing the right form of learning for every correction.
We believe this decision itself should be made by an agent swarm: specialists that interpret the feedback, inspect the current agent, propose competing changes, generate evaluations, and test the new behaviour before anything reaches production.
The evaluations must also be generated automatically. Business users can explain that an outcome was wrong, but they cannot be expected to design regression suites, adversarial cases, or behavioural tests. The system has to translate ordinary feedback into a durable lesson and proof that the lesson works.
This is why agent swarms matter so much to us. They do not merely execute more work in parallel. They solve one of the hardest problems in the product: safely improving the agents themselves.
Teaching an agent is closer to changing software than editing a profile.
An agent's behaviour comes from instructions, memories, skills, code, files, tools, datasets, credentials, connections, models, and evals. A small change to one can unexpectedly alter the rest.
Every change should therefore land on an isolated branch containing the agent's behavioural state. It should be tested against historical and automatically generated evaluations, inspected as a semantic diff, and merged only when it is demonstrably better.
This becomes difficult once the branch includes more than files. Datasets need copy-on-write semantics. Connections point to mutable external systems. Credentials must remain secure but testable. And two changes that merge cleanly as text may still conflict in behaviour.
The goal is to make agent evolution safe and ordinary: teach, branch, evaluate, merge, and roll back.
The model is only one component of an agent. The harness determines what it sees, which tools it uses, how it plans, when it retries, when it asks for help, and what counts as done.
The same model can look exceptional or incompetent depending on the harness around it.
We think the best harness will learn empirically from production. Every run produces evidence: context choices, tool trajectories, retries, latency, cost, human interventions, and final outcomes. The harness should use this evidence to improve how future work is planned and executed.
Important directions include plan-execute-validate loops, automatic eval generation from failures, outcome-level validation, model routing, durable context for long runs, shadow execution, and observability that explains business decisions rather than dumping raw tool calls.
The winning harness will not have the most elaborate loop. It will produce the most dependable outcome per unit of time, cost, and human attention.
Most company work is already done by teams. A finance process may involve an analyst, approver, procurement specialist, and controller. Agents should be able to organize the same way.
But more agents can also mean duplicated work, inconsistent assumptions, recursive delegation, and runaway cost.
A reliable swarm needs clear ownership, explicit task boundaries, shared artifacts, bounded budgets, and ways to resolve disagreement. It must decide which work benefits from parallel specialists and which is better handled by one agent. It also needs to pass enough context to preserve meaning without copying entire histories between agents.
The right abstraction may look less like a group chat and more like a typed work graph: tasks, dependencies, contracts, artifacts, budgets, and validation criteria.
The goal is not the largest swarm. It is the smallest team that can reliably complete the work.
Retries are not just about trying again. Once an agent has changed the world, retrying may require reversing what it already did.
An agent may create a record, send a message, approve a request, update a ledger, or move money before a later step fails. Starting over can duplicate side effects or leave the process in an inconsistent state. Reliable recovery therefore needs compensating actions: explicit ways to undo, reconcile, or safely continue every state-changing step.
Each action needs an identity, recorded inputs and outputs, an idempotency strategy, and a known reversal path. The system must distinguish between a transient failure, an uncertain side effect, invalid state, missing information, and a genuinely irreversible action.
A dependable agent should checkpoint its work, verify external state before retrying, reverse completed actions when necessary, and escalate when it cannot prove that recovery is safe.
An agent is not reliable because it usually succeeds. It is reliable because failure is contained, legible, and reversible.
The best agent experience will not be a command box. It will feel like working with a colleague.
That includes calls. A human and an agent should be able to work together in a persistent Google Meet-style conversation: discuss a goal, inspect artifacts, make decisions, hand work back and forth, and resume later without losing the shared context.
The agent should understand when it is being informed, asked, corrected, or authorized. It should contribute naturally without dominating the conversation, preserve decisions and commitments after the call, and continue the resulting work asynchronously. When the team reconvenes, it should know what happened and what remains unresolved.
This requires mixed-initiative collaboration. Humans contribute judgment, context, and accountability. Agents contribute speed, recall, parallelism, and persistence. Control should move between them fluidly as uncertainty changes.
The goal is not to remove humans from the loop. It is to build a team that performs better together than either could alone.
Most agents execute processes. A true digital employee should eventually own an objective.
"Generate this report" is a task. "Reduce invoice exceptions by 30%" is an objective. The second requires the agent to form hypotheses, run experiments, measure outcomes, manage a budget, and adapt over months.
This is hard because metrics can be gamed. An agent optimizing resolution time may close cases prematurely. One optimizing outreach may send more low-quality messages. Objectives need guardrails, counter-metrics, budgets, and clear limits on how outcomes may be pursued.
A goal-driven agent must maintain a durable model of its strategy: what it believes, what it tried, what changed the metric, what failed, and why the next action is worth taking. Humans must be able to inspect that strategy, approve irreversible moves, change the mandate, or stop the agent.
The leap is from assigning work to entrusting an outcome.
Today, most companies rent intelligence from a small number of model providers. We want every enterprise to be able to own its own.
An agent platform naturally accumulates valuable training data: successful tool trajectories, failed attempts, human corrections, approval decisions, and golden evaluations. That data can be used to train private, open-source models specialized for the company's work.
Over time, a customer should be able to move a mature agent from a public model to a model it owns, without rebuilding the workflow. The model could run inside its cloud or an air-gapped environment, with predictable cost, low latency, and full control over its data and deployment.
The hard parts are selecting trustworthy traces, removing sensitive data, preventing memorization, covering failures and edge cases, and continuously proving that the specialized model remains as reliable as the system it replaces. Smaller models may excel at one decision but still need frontier models for planning or recovery, so routing must happen at the level of individual capabilities.
The goal is not open source for its own sake. It is a world where intelligence becomes an asset a company can own, improve, govern, and deploy on its own terms.
These problems depend on each other. Learning without version control creates drift. Version control without evals cannot prove improvement. Swarms without durable execution multiply failure. Objectives without governance turn autonomy into risk. Owned models without a strong harness reproduce the weaknesses of their training traces.
The common challenge is converting probabilistic intelligence into an accountable operating system.
That will take better abstractions for learning, execution, collaboration, evaluation, and control, tested against real company work. Solving them is how agents move from impressive software to dependable colleagues.