Multiplayer AI Should Not Require Your Team Using GitHub

Emily Kramer recently published a smart framework for getting marketing teams out of "single-player Claude mode." Her central argument is exactly right: the next major AI productivity gain will not come from making one enthusiastic marketer even better at prompting. It will come from turning what that person learns into shared infrastructure for the whole team.

She’s completely correct about the destination and also honest about the cost involved getting there. From our perspective, however, the cost is the problem.

The destination: compounding momentum

Today, most useful AI work remains stuck with the individual who created it. One marketer develops a strong research process. Another builds a reliable content workflow. Someone else gives Claude enough background to finally produce an accurate sales brief. Each person gets faster, but the team does not necessarily improve with them.

Multiplayer changes that: context is shared, useful capabilities spread, and correction made by one person improves the next result for everyone. What this means is that, instead of repeatedly starting from zero, the team builds on its own work, and momentum compounds.

Is there proof that this is worth it?

A recent analysis of 3.8 million messages on elvex showed what happens as a multiplayer harness takes on more of the assembly and execution. Median message length dropped 23%, from 164 to 127 characters. Tasks became more complex, with requests per conversation rising 60%, from 5.25 to 8.42. Satisfaction climbed from roughly 50% to 79%.

This happened because the harness was helping the users, not because they magically became expert prompt engineers overnight. 

That is the behavior a multiplayer system should create. People provide less mechanical instruction while accomplishing more difficult work. The knowledge required to get a good result moves out of each person's prompt and into shared company infrastructure.

The cost of getting there

Kramer is onto something important. She also captures why so few teams have reached this point: building a shared AI system is a lot of work.

Her recommended setup uses Claude, Claude Code, Cowork, MCPs, a shared GitHub repository, plugins, skills, context files, publishing processes, maintenance routines, and a designated owner. None of those components is unreasonable. GitHub is not even particularly difficult once someone shows you how it works.

But you are simply not going to get everyone on a marketing team to start using GitHub. Some will. Most will not. They have campaigns to launch, copy to review, reports to prepare, and pipeline targets to hit. They did not join the marketing team to manage local repositories, resolve versioning questions, or decide whether a correction from a chat should be committed to a shared skill file.

Now apply the same expectation to sales. Then accounting. Then HR, legal, operations, customer support, and every other nontechnical function.

If multiplayer AI depends on the whole company learning developer workflows, it will remain the domain of small groups of highly motivated enthusiasts. 

The destination is right. The route asks too much of the people who are supposed to benefit from it. Fortunately, companies do not have to build multiplayer AI this way. The collaboration layer can be a product.

From individual productivity to organizational capability

The first phase of workplace AI was almost entirely single-player. Employees opened ChatGPT or Claude, typed requests, and received answers. The best users learned to add more instructions, upload better documents, and construct elaborate prompts. They created personal workflows that saved hours of work.

A senior marketer could spend months teaching Claude how the company speaks, what the product does, which customers matter, and how a good campaign brief should be structured. A colleague opening a new conversation still started with none of that knowledge. The senior marketer got better at using AI. 

However, the company did not permanently acquire the senior marketer's method, and this is the distinction between adoption and transformation.

Adoption means many employees have access to AI. Transformation means the organization has a new, more effective approach to work. The best way to make transformation happen is an AI habit that gets better each time those employees use it. A multiplayer system makes that possible. 

The best person on the team does not merely produce better work. Their expertise raises the starting point for everyone else.

That is the opportunity Kramer identifies, and it extends far beyond marketing: sales, operations, HR, finance…everyone can benefit.

The DIY version reveals what the product needs to do

Kramer describes four ingredients for multiplayer Claude: Claude, context, capabilities, and collaboration. It is a useful way to understand why a shared account or folder full of prompts is not enough.

A real multiplayer system needs current company knowledge. It needs repeatable ways to perform work. It needs a mechanism for distributing improvements. It needs ownership, testing, maintenance, and trust. In a DIY setup, a team has to assemble those pieces itself.

Someone must decide where the canonical context lives. Someone must connect the relevant tools and data. Someone must turn successful work into reusable skills. Those skills need to be tested, published, updated, and audited. Team members need compatible local setups. Changes need to reach everyone. Duplicate or stale capabilities need to be identified. Permissions and sensitive information need to be managed separately.

This is a reasonable experiment for a technically confident team. It is not a reasonable operating model for an entire company.

The setup also creates a familiar organizational problem. The person who knows how to build the system is often not the person who leads the function. The function leader understands the work but may not understand the infrastructure. Everyone agrees that a shared system would help, but nobody has time to stop doing the work long enough to build and maintain one.

The harness is the product: here’s how we think about harnesses

A model provides intelligence. A harness turns that intelligence into useful work.

Ask a raw model to "write a sales follow-up email," and it will produce something generic. Give the same model the CRM record, meeting transcript, relevant product information, approved messaging, prior correspondence, and a clear way to review and send the result, and the same short request can produce an immediately useful email.

The difference is what the harness assembles around the prompt, not the user’s prompt itself.

For every request, a strong harness determines what the model needs to know, what tools it can use, what the person is allowed to access, what work has already been done, and what should happen next. It retrieves the relevant information without forcing the employee to reconstruct the company's knowledge in every conversation.

A useful way to think about this system is through five connected concepts:

Models are commodities that provide intelligence

The model is the reasoning engine. It interprets the request, works through the task, and generates or selects the next action.

Models are important, but they are inputs to the system rather than the system itself. Different jobs require different levels and types of intelligence. The best choice will continue to change as new models arrive. A company's workflows should not have to change with them. 

Most importantly, companies should not be paying full price for frontier models like Claude and ChatGPT when there are others that are just as capable for 5% of the cost. 

The harness automatically collects context

The employee should not have to tell the model everything the company already knows.

A harness can collect and maintain context from the person's role, active work, previous conversations, shared team knowledge, company systems, connected tools, and the resources available to them. It can then retrieve the relevant portions for the task at hand.

This does not mean stuffing every available document into every prompt. More context is not automatically better. Irrelevant context increases cost and distracts the model.

The harness should keep information available, understand how it relates to the person and task, and bring it forward when useful. The employee types less because the harness handles more of the assembly.

Resources are singular pieces of context for a purpose

Resources are the individual building blocks the harness can use.

An agent can contain instructions and behavior for a particular job. A datasource can provide company knowledge. An integration can retrieve information or take action in another system. An artifact can preserve work the company has already produced. Other resources can carry settings, tools, evaluations, or task-specific material.

Each resource exists for a defined purpose. It can be created once, improved over time, and made available wherever it is relevant. Importantly, it is cloud hosted and automatically updates for everyone when someone saves a change.

This is the productized version of the skill files, context documents, connectors, and workflows that teams otherwise have to manage by hand.

Shared spaces bring resources and people together

A useful AI system needs to understand that people work with colleagues toward shared goals.

Shared spaces are where multiple resources come together for a team, project, or function. A marketing space might include the company's messaging, customer research, content agents, CRM integration, campaign artifacts, and current plans. The people responsible for that work receive access to the space and the resources inside it.

A sales space would contain a different combination. So would HR, accounting, legal, or a cross-functional product launch team.

This makes context multiplayer without making all context universal. People receive the resources needed for their work, within the boundaries appropriate to their role.

When someone adds a useful resource to the space or improves an existing one, the rest of the authorized group benefits. The shared system gets better without asking every participant to pull a repository, install a plugin, or update a local configuration.

The agent itself can choose which resource is appropriate for which task, from within that managed Space.

In a practical sense, what this means is that your employees don’t need to remember where to find 30 different agents or datasources or other resources. You can just point them to their team-specific Space, where it’s all organized already for them. It reduces the cognitive load significantly.

Control exists at every layer

Multiplayer without control becomes chaos.

Companies need control at the company, personal, resource, and space levels. They need visibility into what people and agents are doing. They need permissions that determine who can see, use, edit, or share a resource. They need governance over connected data and actions. They need a record of how the system is used and where it is producing value.

They also need economic choice.

Control should not mean forcing every employee into a rigid, centrally designed workflow. It should provide safe boundaries within which people can experiment, build, and share what works. The best systems make the governed path easier than shadow AI, not merely more restrictive.

This is where a harness can do what a collection of local files and personal subscriptions cannot. It provides one environment where experimentation and oversight reinforce each other.

Model independence makes multiplayer affordable

There is another problem with centering the shared system on one model provider: every successful workflow also becomes tied to that provider's pricing.

For the last few years, defaulting to the newest frontier model was rational. The quality differences were meaningful, the use cases were uncertain, and the easiest advice was to throw the best available intelligence at every problem.

That reflex now creates enormous waste.

Summarizing a meeting does not always require a frontier model. Neither does classifying a support request, drafting an internal FAQ, retrieving a policy, transforming a document, or following a well-defined workflow with strong context.

Open-weight models can now perform much of the everyday work people ask AI to do. Through an independent harness, companies can complete that work while spending 95% less on token bills.

That reduction changes what a company can attempt. It is not merely a procurement win.

When every experiment runs on the most expensive model available, teams become cautious. Managers limit access, promising workflows are kept inside small pilots, employees worry about usage, and successful applications create budget anxiety precisely when the company should be expanding them.

At 95% lower token cost, the boundaries move.

Teams can run more experiments, more employees can participate, agents can take on more complex, multi-step work, and a workflow that was too expensive to run across every customer account can become economical. Capabilities proven by one team can be extended to ten more without breaking the bank.

Lower cost gives the company room to discover where AI produces real value. Most experiments will not transform the business, and that is exactly why experimentation needs to be cheap. The company can try more ideas, learn faster, discard weak workflows, and scale the ones that work.

The result is a healthier adoption loop:

1. More people can experiment.
2. Successful work becomes a shared resource.
3. Shared spaces distribute that resource to the right groups.
4. Usage generates more corrections and institutional context.
5. The harness improves the system.
6. Lower model costs make the next round of experimentation affordable.

The value and the momentum compounds, while the marginal cost remains manageable.

The harness can make a less expensive model more useful

Model comparisons often treat the prompt as the entire input. Give two models the same isolated instruction, compare the outputs, and declare a winner. That is not how useful workplace AI operates.

The model inside a strong harness receives relevant company context, access to appropriate tools, examples of accepted work, knowledge of the user's role, and a workflow designed for the task. It does not have to infer the entire situation from a few sentences.

A more expensive model without that context can produce worse work than a less expensive model inside a well-designed harness. This is why the model is becoming a commodity input for many enterprise tasks. The model still matters, but much of the practical value comes from the system that focuses it.

The good news is that this already exists: try elvex

Emily Kramer is right. Single-player AI is not enough. The best person on the team should make everyone better.

The next step is to make multiplayer itself part of the product.

The model is the commodity input. The harness is where the company's context, capabilities, collaboration, and control become permanent. And that is where AI finally starts producing company-wide results.