MobAI – When AI Becomes a Member of the Team

In many organizations, AI is adopted one person at a time. One person makes slides with Copilot, another analyzes test results with the help of AI, and a third uses it to test code.

This can speed up individuals' work. But complex product and service development is not just an individual productivity problem. It requires a shared picture of the situation, an understanding of the business and the customer, collaboration between experts from different fields, and continuous decision-making.

That is why the next step is not just an even better personal AI assistant.

It is AI that works as part of the team.

That is what MobAI is for.

AI as part of shared work

MobAI® combines mob working and AI. The team works together on the same real problem at the same time, assisted by AI.

AI can help with, for example, finding information, generating alternatives, programming, analysis, and building prototypes. People bring the goals, business understanding, experience, judgment, and accountability.

This is not a situation where one person writes prompts and the others watch. Nor is it one where everyone works separately with their own AI and the results are then somehow fitted together at the end.

In MobAI, the team is the basic unit of learning and doing. AI is not a tool outside the work but one participant in the shared effort.

The term MobAI was first used by Joe Justice in May 2023. The method builds on mob programming, or software teaming, popularized by Woody Zuill: the whole team works together on the same thing. MobAI adds an actively participating AI to the work. (Joe Justice and Agile Business Institute)

From coding team to builder and supervisor of agents

Coding agents can already design solutions, write and test code, and use various tools independently. The next step in this development is agent teams and swarms made up of several specialized agents.

This does not remove the need for a human team. Quite the opposite.

The more independently agents operate, the more important their goals, boundaries, access rights, evaluations, and oversight become. People need to be able to understand:

• what task each agent is performing
• what data and tools it uses
• what it hands over to the next agent
• on what basis a result is accepted
• at what point a human decision is needed
• how faulty behavior is stopped.

MobAI offers a practical team model for this.

The driver operates the shared tool. The navigator helps choose the next step. The rest of the team evaluates the agent's suggestions, contributes the necessary expertise, and follows the progress of the whole. Roles rotate regularly so that skills, responsibility, and understanding do not stay with one person.

The work proceeds in short rounds. In WikiAgile's exercises we have used 7-minute iterations. After each round, the team reviews what the agent did, what was learned, what needs to be tested, and what additional context the next round needs.

In this way, a coding team does not merely use ready-made agents. It learns together to build, steer, evaluate, and improve them – and to carry responsibility for their behavior.

In MobAI thinking, the human team forms a continuous feedback, oversight, and learning loop around the agents. Without evaluation, an agent's behavior can drift away from the goal set by people.

An agent may, for example, learn to optimize the wrong metric or to pass a test without solving the actual problem. A coding agent might make all the tests appear green by changing the tests instead of fixing the software. This is called reward hacking. (OpenAI: How we monitor internal coding agents for misalignment)

In an agent swarm, one agent's faulty assumption can pass to the next agent and become the starting data for its work. In this way even small errors can compound and produce unexpected system-level consequences. (Anthropic: Patterns and problems in emerging multiagent systems)

The goal is not for a human to manually approve every intermediate step an agent takes. That would eliminate much of the speed agents bring. The goal is to build fit-for-purpose oversight: agents operate within agreed boundaries, their work leaves a trace, deviations are detected, and risky situations are escalated to people.

At the same time, the team uses the feedback to improve the agents' instructions, evaluations, algorithms, and guardrails.

MobAI is not just a coding method

MobAI can also be used when the aim is to move quickly from a business need to a working prototype.

Not everyone needs to know how to build AI agents. Nor is it worth training everyone to be an expert in agent development. Instead, the same team can bring together people who know the business and the process, product management, someone skilled in building agents, and the necessary security, legal, and technology experts.

A usability designer can, for example, build a prototype together with the business, product management, and an agent specialist. The need, the user experience, and the solution are refined simultaneously, instead of the task moving step by step from one department to the next.

The same principle works in hardware development. A simulation of a physical product or component can be built together with a hardware expert, a software specialist, and AI. The simulation does not remove the need to build the physical product, but it brings feedback and learning earlier.

MobAI is also a method for change.

Training on the possibilities of AI alone does not usually change how an organization works. People need to experience what the new kind of work feels like.

In WikiAgile's workshops we have used, for example, robot programming as a learning vehicle. Participants do not need to know Python or robotics beforehand. They experience in practice how a multidisciplinary team can, with the help of AI, learn quickly, experiment, fail safely, and reach a result.

After that, the same way of working can be applied to the organization's own products, services, and processes.

MobAI is already being applied beyond software development

MobAI is a young concept, so there are still few publicly documented company examples. However, in addition to software, the method has been used in areas such as hardware and electronics design, production robotics, embedded systems, product design, business development, and training.

In Sweden, MobAI has been taught at KataCon Europe, among other places. In the publicly described TRATON example, a development team began using shared, daily mob working sessions supported by AI. The goals were faster problem solving, reducing dependencies on key individuals, and strengthening shared ownership. (The TRATON team's experiences)

In Finland, we at WikiAgile have used MobAI in product development, leadership, and organizational change. The core of the method is not a particular task or industry, but the fact that the people, expertise, and AI needed to solve a problem start working together.

AI-Native SAFe is heading in the same direction

Scaled Agile announced AI-Native SAFe in June 2026 and presented it in full at the SAFe Summit in September. It is not just a matter of adding AI features on top of the old SAFe framework, but an operating model intended for the AI era. (AI-Native SAFe announcement)

AI-Native SAFe does not use the name MobAI. Its team model nevertheless contains many of the same core elements.

An AI-Native team combines product expertise, building expertise, domain expertise, and AI. People retain responsibility for decisions and quality, even though agents speed up implementation. Work proceeds as a continuous flow of directing, observing, and responding. (AI-Native Teams, Roles and ARTs)

AI-Native SAFe also emphasizes oversight of autonomous agents. Governance consists of rules, automatic detection of deviations, and human judgment. (AI Governance and Ethics)

So AI-Native SAFe does not name MobAI as part of its model. Its team model nonetheless reflects the same fundamental shift from individual use of AI to shared and supervised AI work.

You don't become AI-native by buying more tools

An organization does not become AI-native by getting everyone an AI license.

The change happens only when AI is connected to shared work: defining problems, exploring alternatives, experimenting, making decisions, and learning.

MobAI makes this change visible, safe, and something that can be practiced.

When AI becomes a member of the team, the question is no longer just how quickly one person can get more done.

The question is how quickly the whole team can learn, oversee the AI, solve real problems, and turn ideas into value.