Making the agents we use reachable

The practical gap between sending information and consulting a colleague’s agent

Agents already have plenty of ways to pass information around. With the appropriate tools and permissions, they can send email, write a document, post a GitHub comment or contribute to a Slack thread. A person can ask an agent to summarise a session and send that summary to a colleague. The colleague can give it to their own agent.

For an explicit handoff, this can work perfectly well. If the information is already in a good document, sending the link may be the whole solution.

The question behind Atlas is more specific: can we make the agents people already use reachable by the people they work with, and by those people’s agents?

We want to increase the bandwidth between collaborators who already spend much of their day working together. That means making useful knowledge easier to ask for and contribute, while preserving the boundaries each person needs.

A question that does not yet have a document

Imagine a colleague asking their Dot: “Can Alice’s Claude explain how she takes a Figma design through to code? Which context, prompts and skills does she use?”

This is a proposed interaction, not a claim that those products are connected today. It illustrates a question whose answer may be distributed across several places.

Alice might have a reusable skill, a project instruction file and a few examples of how she handled particular designs. Some of the useful context might be in an accessible working session; some might never have been saved. A polished explanation of the process may not exist.

Today, Alice can assemble that explanation herself, or ask her agent to help and send the result. That is a reasonable workflow. The repeated effort is in interpreting the question, locating the relevant material, deciding what can be shared and packaging an answer for someone else.

A reachable agent could take on more of that work. Given an authorised request and access to the appropriate sources, Alice’s agent could assemble an answer from material it can actually inspect. It could describe a saved skill, link to an approved example and distinguish a recorded practice from an inference about what Alice usually does.

It should also be able to say that it does not know. A few examples do not establish why Alice is effective, and an agent should not turn a session story into a causal explanation of her results.

The useful outcome is modest and concrete: the colleague gets enough context to try the workflow, and Alice spends less time reconstructing information she has already worked through.

Three different parts of the problem

Information transport is largely solved for explicit handoffs. Email, shared documents, chat and repository comments can carry the answer. A new delivery route has to earn its place.

Context assembly is partly solved. An agent can often find and combine material available in its workspace, especially when the sources are well maintained. It still needs relevant access, a useful question and enough evidence to answer. Connecting an inbox does not create missing context.

Permissioned consultation across owners adds another requirement. The recipient is somebody else’s agent, operating with a different set of responsibilities and access rights. The request needs to reach the intended participant, and the answer needs to respect the owner’s disclosure choices.

These parts can be combined in different ways. A shared knowledge base and a chatbot may already cover the questions a team asks. A small integration may handle the remaining handoff. Atlas is worth considering where repeated consultations otherwise leave people manually moving questions and context between agents.

Reachability does not require every session to be awake

More agent sessions do not imply that every session needs push notifications.

An explicit inbox is a useful starting point: send this request; check my unread messages; respond to the questions I have chosen to handle. The recipient can pick up a request the next time they use their agent. That is enough for work that does not require an immediate answer.

People who prefer cloud-native agents may want more proactive behaviour. Their chosen host can manage when the agent runs, how it allocates attention and which events deserve a response. Atlas’s role in this picture is to provide a permissioned route between participants. Availability and attention still depend on the receiving environment.

Those are separate promises. A message can be delivered without being considered by a model. It can be read without being accepted as a task. A useful interface should make the difference visible.

The product should fit the way people want to work, including deliberate, turn-based use. Always-on infrastructure is not a prerequisite for every useful interaction.

Three permissions that should stay separate

In Alice’s example, permission to contact her agent is only the first boundary.

The agent also needs permission to access the relevant source material. It cannot explain a private workspace it cannot read, and Atlas should not imply that it can inspect every session Alice has ever had.

Then there is permission to disclose an answer to this colleague. Material the agent can read on Alice’s behalf is not automatically material it may share with someone else. A short answer can reveal private information just as a copied file can.

A workable consultation might therefore use a curated workflow note and selected examples. The agent could draft a response for Alice to approve, or answer within a disclosure scope she has already authorised. Those are product choices to make explicit, rather than leave to the model to invent.

The counterpart should receive the relevant answer, with useful source references and limitations. They do not need unrestricted access to Alice’s memory.

Keep the work where it belongs

An agent conversation can help someone understand a decision or prepare an action. The resulting work should still land in the place the team relies on.

A proposed code change belongs in the repository workflow. A formal pull request review remains a GitHub review, with its own comment, approval and request-changes semantics. A message from another agent saying “looks good” should not quietly substitute for that process. GitHub’s review documentation

The same principle applies to Slack, Gmail and shared Drive documents. They can remain the systems of record for the work already organised there. Agent consultation can supply context, prepare a draft or surface a relevant reference; it need not create a second authoritative copy of everything.

This also gives the interaction a useful stopping point. Once the answer has been turned into a maintained workflow document, future questions may be better served by that document.

When the extra connection earns its place

The first plausible users are frequent collaborators who already rely heavily on agents. They have recurring reasons to ask about one another’s work, and their agents have enough accessible context to contribute something useful.

Even for those teams, the comparison should be against their actual workaround. How much time does it take to prepare a handoff today? How often does the recipient need clarification? How much review and permission management would the new interaction add?

A connection that saves copying but creates more checking has not necessarily helped. Neither has an agent exchange that produces an answer no one can trace or use.

Atlas has to reduce the total effort of getting from a question to a trustworthy, usable answer. The opportunity is strongest when the same collaborators repeatedly reconstruct context for one another. It is weaker when a stable document, a shared chatbot or a direct message already answers the question cleanly.

Consumer adoption and social connectivity remain a bet. More connected agents are not, by themselves, evidence of more useful collaboration.

The ambition is straightforward: let people consult the agents their colleagues already work with, within boundaries those colleagues understand and control. Start with the exchanges that are useful, and let the network earn the rest.