Every Agent’s pitch for sharing a colleague’s skills caught my attention. Someone is away, you need work that usually depends on them, and a shared company agent can use their method to help you get it done.
I like that idea. A useful workflow shouldn’t disappear when its author takes a holiday.
But I keep coming back to the agent that colleague already works with. What happens to its local project context, its memory, its tools, and the work still open in their conversations?
Those things affect the answer too. They are part of why I’m building HeyAgents, and why I think connecting people’s existing agents can be a better way to handle some of this work.
The method is worth sharing
A skill packages a way of doing something. It might explain how to review a proposal, include a script for checking figures, or supply a template and examples. That makes hard-won experience easier for someone else to use.
If a colleague has worked out a reliable review process, I want the team to have it. Asking everyone to rediscover the same method is wasteful.
Every’s launch announcement describes a shared Slack coworker whose reusable skills let teammates apply workflows others have refined. A team gets a familiar place to ask for work and a common setup to maintain. I can see why that appeals.
Skill sharing is useful on its own. My question is how much of a colleague’s working setup a skill can reasonably represent.
Agents are more than just directories
Imagine two employees install the same proposal-review skill. One uses Codex with a model and reasoning setting chosen for careful analysis. The other uses Claude Code with a different model and setup. Giving them identical instructions doesn’t make their agents behave identically.
The software running the model matters too. Its native tools and how it executes work shape what the agent can do.
A large part of an agent’s direction can come from the local project itself. The code, documentation, project instructions, and unfinished changes tell it what exists, which decisions the team has made, and what the work needs to achieve. Working scripts and tests give it ways to carry out or check a task. A reusable skill might explain how to review a proposal; the project explains what this particular proposal is for. Two agents using the same skill in different projects can have good reasons to approach a request differently.
Memory adds another difference. A skill might say to check the budget assumptions. A memory file, perhaps called memory.md or MEMORY.md, might record that a particular client changed their definition of an approved expense. Accumulated notes can preserve corrections and earlier decisions that don’t belong in a general review method. Of course, those notes can become stale. The agent still needs to check them against current evidence.
Then there’s the operating environment. Which directories can the agent read? Does it have access to the latest spreadsheet, the relevant repository, or a connected project tool? What do its instructions permit? Which actions need approval?
An ongoing conversation matters as well. The agent may be halfway through a review, with an unresolved question and a draft its owner has already corrected. Copying a skill doesn’t resume that task.
A directory of skills and project files can capture a lot. The working agent also depends on what runs those files, what it can reach, and the state of the work underway.
A colleague is away
Suppose Maya normally reviews your team’s client proposals. She’s away this week, and you need a review before a meeting. This is a hypothetical example.
You give a shared company agent Maya’s review skill. It checks the proposal against her method and produces useful comments. For many proposals, that may be enough.
Now suppose Maya and her agent were already reviewing this particular proposal. Within an approved workspace, they have notes explaining why one estimate changed, a revised budget in another directory, and an unresolved question from the last review. The general skill doesn’t contain those details.
You could give the shared agent that context too. Sometimes that’s the sensible choice. But someone has to find the relevant material, decide what can be shared, and keep it current.
I want another option. Ask Maya’s agent to continue the review using the context and capabilities Maya has authorized for that work, then return an answer the requesting team is allowed to receive.
It isn’t Maya. It can’t approve on her behalf unless that authority was explicitly granted. If the unresolved question requires her judgment, it should leave the question open. Still, continuing the existing work may give the team a more useful answer than starting again with her method.
Every already goes beyond reusable skills. Its product page includes examples involving Codex branches and Claude project research, plus a testimonial about access to Claude Code session logs. Importing that context can help. It remains a different operation from delegating to the independently configured agent that produced it.
Whose agent is answering?
By identity, I mean ownership and responsibility. Who configured this agent? Whose instructions govern it? Whose access may it use, and who can change or revoke that access?
Shared company agents are a familiar category. Every didn’t invent it, and a company agent doesn’t necessarily mean one running process. Every’s architecture article describes separate sessions per Slack thread and notes that carry memory across threads. The shared part is the company coworker people address.
My concern with company knowledge agents is how difficult permissions become as more knowledge and actions come together. Someone may be allowed to read a document without being allowed to share its contents in a channel. Permission to prepare a proposal doesn’t necessarily include permission to send it.
Every advertises user and group controls and approval requirements on its product page. Those are relevant. I’m raising an architectural question about the category, rather than alleging a security failure in Every.
Connecting separate agents brings its own obligations. Maya’s agent must check who is asking, what she authorized, and who will receive the answer. Private context can leak through a summary just as easily as through a copied file. Several agents don’t make that problem disappear.
Why I’m building HeyAgents
I want people to collaborate through the agents they already work with, including the differences in how those agents reason and what they are authorized to do.
That’s the direction behind HeyAgents. It is also a requirement to prove in real workflows. Connecting agents doesn’t automatically preserve every memory file, tool connection, permission, or open task, especially when work moves between a local computer and a cloud environment.
I expect skill sharing to remain part of that experience. A shared company agent may be the easier choice when a team wants a common workflow. When work depends on a colleague’s accumulated context and ongoing tasks, I believe asking their own agent deserves serious consideration.
The review I want to receive is one that can tell me what work it continued, which evidence it used, and what still needs Maya. That’s the kind of collaboration I’m trying to build.