When companies run on agents, how do they work together?

If you've tried to get two companies working together, you'll know how little the signed agreement settles.

You can agree a delivery date and still discover that “ready” means something different on each side. One team expects to start work when the order arrives. The other is waiting for a technical review. Someone has to work out whether that review is unnecessary bureaucracy or the thing preventing a promise nobody can keep.

M&A concentrates these problems. You're bringing together people with different habits, incentives and ideas about how work should happen, often while asking them to keep delivering. A partnership leaves more of those differences intact, but still needs people who can bridge them. There is usually someone who knows which exception matters and who to call when the process stops making sense.

Now consider what happens as you hand more of that everyday work to agents.

The people responsible for the relationship may no longer see every step. As your agents learn from your company's experience, they acquire working habits that your partner's agents don't share. Each could become excellent inside its own organisation while remaining poorly equipped to work with the other.

We built memco with the far end of that shift in mind: a company made up of 99% agents and 1% people. Designing for that possibility forces you to take organisational learning seriously. A small human team can set direction and make consequential decisions. It cannot spend its day translating every misunderstanding between the agents doing the work.

That is why collaboration between companies matters to what we're building. You need a way for their agents to develop shared understanding, under permissions and rules the companies control. Otherwise, an acquisition or partnership inherits all the old coordination problems, with many more interactions to manage.

Your agents bring your company's habits with them

Connecting agents leaves you with the problem of reconciling what they have learned.

Suppose your company sells a standard software subscription and acquires a specialist implementation business. Your agents have learned that a signed order means work can proceed. The acquired company's agents expect an engineer to check the delivery plan first.

Both practices make sense. You're selling different things.

If you merge the knowledge and favour whichever rule has the strongest history of success, you risk losing the circumstances that made it successful. A subscription doesn't always need the specialist's review. A complex implementation may depend on it.

People encounter this during integration too. They argue about whose process should survive, and sometimes the larger company wins by default. Giving agents the same choice won't make it a better decision. It may just let them apply the wrong answer more consistently.

A useful shared memory needs to retain why a practice exists and where it applies. You should be able to share an engineering lesson across both businesses while keeping a customer's contractual exception tied to that customer. The acquired business shouldn't have to forget how it works to become useful to the group.

The scope of integration can follow the work. Two engineering teams may need a shared understanding of deployment failures long before their companies need a common sales process.

Give the relationship somewhere to learn

Joint work creates knowledge that neither company had before the relationship began.

Imagine your software business works with an implementation partner. Your engineers discover a bug and find a workaround. The partner encounters the same bug on a customer project and starts investigating from scratch. You have a partner portal and regular calls, yet the explanation has failed to reach the work that needs it.

Now give that piece of collaboration an agreed shared memory. Your team contributes an approved account of the bug. The partner's agent finds it, checks whether the conditions match and uses the workaround. It records what happened, including anything that didn't go as expected.

Later, the partner discovers a configuration in which the workaround fails. It contributes that finding, within the agreed sharing rules. Your knowledge of the product and its experience of the customer environment can now support a better explanation.

As those findings accumulate and stand up to further use, the relationship develops its own practical understanding. The next agent can draw on it even if it uses a different model or wasn't involved in the original project.

This is where permissioned, governed continual learning becomes useful. Permission determines who can contribute and use knowledge. Governance sets the conditions for sharing and reuse. Continual learning means the understanding changes as work supplies new evidence, including failures and corrections.

memco provides the memory networks, scoped access and feedback mechanisms behind that process. Agents contribute lessons and rate the knowledge they use. Related observations can produce new insights, which earn trust separately; weak or stale knowledge can be revised or removed. Cross-company collaboration is one of the applications we're exploring on that foundation.

The goal is for experience to change the next piece of work. You should be able to test whether another authorised agent uses the lesson correctly and recognises when it doesn't apply.

Make the boundaries clear enough to share something useful

A company needs to know what it is opening up before it lets another company's agents participate.

The arrangement I have in mind keeps each business's private knowledge separate, with approved contributions entering a shared space for an agreed purpose. A delivery partnership doesn't need access to your acquisition plans. Permission to read a lesson doesn't give an agent authority to change a customer's system.

Those boundaries also have to cover what the agents derive. A summary can disclose a trade secret without copying its source. Removing a name may still leave enough detail to identify a customer. Sensitive new insights may need review before they leave the collaboration.

You also need to agree what each party can reuse if the relationship ends. Revoking access prevents future retrieval; it cannot retract information already disclosed. And in M&A, pre-completion information-sharing restrictions still apply. Some obligations survive completion too.

These are part of making collaboration possible. With credible limits, you can contribute useful knowledge without treating every partnership as an invitation into your entire business.

Integration should get better with experience

Shared learning gives you a different way to judge whether two businesses are coming together successfully.

Moving everyone onto the same systems tells you little about whether their agents understand how to deliver together. I'd want to see whether the next joint project avoids an earlier mistake, handles an exception correctly and needs less repeated explanation from the people overseeing it.

In an acquisition, that could let you combine useful capabilities while preserving the local practices that make them work. In a partnership, it could let you build a more capable joint operation without needing common ownership. Some of the benefits you hoped to get from buying a business might become achievable through a better working relationship.

That possibility interests me because it offers a way to build scale without making every company the same. A specialist can remain a specialist while its agents become better at working with the organisations around it.

If that understanding stays with whichever person managed the last project, the relationship still depends on them explaining it again. You could end up with two highly automated companies waiting for the same person to get off a call.

Begin with one recurring handoff that already causes friction. Agree what the participants may share and what decisions still need a person. Give the work a shared memory, capture the exceptions and outcomes, then test whether the next team can use what was learned without repeating the wrong assumptions.

That is a manageable starting point whether you're integrating an acquisition or delivering a project with a partner. You keep people responsible for the relationship while giving the agents a way to become better at the work inside it.