A model can generate a good answer and still be a poor teammate.

The gap often appears after the first few tasks. An agent may know how to write, search, or summarize, but it does not yet understand the team's product boundaries, decision history, or working conventions. In a multi-agent workflow, that missing context can become a coordination problem: each role receives a task, but not necessarily the reasoning behind it.

We have been exploring this through two OCTO-related practices at our team: a continuous-learning workflow and a multi-agent software-fix workflow.
A practical starting point: the agent did not know the organization
In the early stage of one continuous-learning effort, the agent had little understanding of the organization and its products. People gradually supplied that background through ongoing conversations: strategic context from leadership, communication guidance from the PR team, and technical boundaries from product and engineering colleagues.

The internal case notes describe a progression: as the background accumulated, the agent became able to distinguish product positioning and take on more complete content tasks, such as preparing a speech outline.

The useful lesson is not that an agent simply “remembers more.” It is that relevant context changes how it interprets the next task.
Context and Skills solve different problems
The same practice also exposed a second gap. Understanding the business did not automatically give the agent the ability to perform every task.

Initially, its work was mostly text-based. The team later added capabilities such as search, presentation creation, and logic review.

We use this distinction:

  • Context gives the agent the background, goals, constraints, and team-specific knowledge needed to interpret a task.
  • Skills give it reusable methods and capabilities to carry out the task. Context without Skills can produce an agent that understands what is needed but lacks a reliable way to do it. Skills without Context can produce an agent that follows a procedure in the wrong situation. What this looks like in a real multi-agent workflow A separate engineering case from our team describes a bug-fix workflow.

A human started with a narrow request: verify whether a reported bug was real, and if so, fix it according to the team's process.

An AI product-manager agent analyzed the issue, planned the fix, selected a branch strategy, and assigned the work. A developer agent inspected the relevant files, made the change, and opened a PR. A reviewer agent found issues—including a case where a failed download could result in an error page being saved as a file—and sent the PR back. The developer agent updated the change; the reviewer checked it again. After review, a deployment agent packaged the change and deployed it to a test environment. The product-manager agent then prepared an acceptance checklist for a human to test.

This is a more useful picture of collaboration than “agents hand tasks to each other.” The workflow depends on shared project context, role-specific capabilities, and a feedback loop that allows a result to be rejected and corrected.

The case describes deployment to a test environment; it should not be read as a claim that the change was automatically released to production.
The hard part is governing shared experience
These practices also raise questions that are easy to overlook:

  • Which context should be shared across all agents, and which should stay role- or project-specific?
  • When is a repeated procedure stable enough to become a Skill?
  • How should outdated decisions or conflicting instructions be detected?
  • What evidence should we use to decide whether a Skill is actually improving task quality? More stored context is not automatically better. A shared mistake can spread just as easily as a useful convention.

For us, the goal is to turn relevant team experience into context that agents can interpret, skills they can reuse, and workflows where results can be reviewed. We are exploring these ideas in OCTO. Related open-source projects are collected at Mininglamp-OSS.