Most of our agents don't work with us yet. They work for us, somewhere else.

We go to their workplace, open a new session, and explain what happened in ours. We give them the background, make a request, wait for the result, and carry that result back to the rest of the team. 

The agent may do excellent work, and it may even save us hours. But the relationship still looks less like working with a colleague and more like hiring an outside consulting agency for a series of small projects. The problem is that the agent exists outside of the company. It’s not privy to the conversation that happened before the request, can't see what changed after the request, and leaves its outputs with the person who “hired” it to action.

That separation limits the full potential of what these agents can do for us. While we've taught them how to complete tasks, we haven't yet given them a true place in the workforce.

Agents have an onboarding problem 

As AI takes on more execution, context and communication become more valuable. Whether the next task owner in a given workflow is a person or an AI agent, they need to know what happened before, what's been completed, and where to focus next.

Companies spend years building communication infrastructure that enables clean handoffs between tasks. We create Slack channels, trackers, shared drives, dashboards, meeting notes, handoff documents, operating rhythms, and more. We intentionally decide where projects live, how a team reports their progress, and who needs to know when something changes. And we spend a lot of time and energy onboarding new employees into those systems because knowing how to do the job is only half of joining a company — you also have to know how the company communicates.

Agents rarely get that same deep, intentional onboarding. We teach an agent to produce the monthly report, but not where to put it. We ask it to research an account, but not how to tell sales what it found. Or we have it update a forecast, but that update ultimately ends in a chat window that nobody else can see. Only the person who ran the agent knows the work happened — and now they still have to download the file, paste the answer, update the tracker, or brief the next person in line.

The agentic output essentially stays silent.

How handoffs turn artifacts into true participation

This is why a fully operational agent can still fail to change how a team works. Most teams judge an agent by the quality of its answer; but an answer is only useful when it enters the flow of work. The next person needs to see it, the next agent needs to know it exists, and both need enough context to decide what happens next.

Human teams solved this problem long ago. When one person finishes a piece of work, they put it somewhere the team already recognizes (e.g. a Slack channel, Notion page, Salesforce record, or database) and signal that it's ready. Agents need the same agreements and “paper trails” to follow. Every agent we build should have clear answers to four questions:

• What information can it read?
• Where does it publish its work?
• How does it signal that the work is complete or blocked?
• Who, human or agent, is expected to act next?

Those answers create a communication bridge, and it’s what separates static artifacts from true agentic participation in a process.

Give the work a place to land

The first bridge is a shared landing zone. An agent should put its output where the team already works, for example, a folder in Google Drive, fields on a Salesforce record, a summary in the Slack channel where the decision will be made, or a row in a table that another process reads.

Being intentional about where the work happens changes how useful it is. When an agent leaves a report in a private chat, only one person can act on it. When it writes to a shared location, the whole team can act on it, or another agent can pick it up without waiting for the upstream agent to come online. Neither agent needs to know the other exists; they only need a shared agreement about where completed work gets dropped off when they’re done.

Case study: Product Cortex at TRM

Product Cortex is TRM’s software development lifecycle, packaged as a Claude Code plugin. Instead of leaving instructions for how software should be shaped, planned, built, validated, communicated, and maintained in documentation, it encodes each phase as a reusable skill. The same process can run when an engineer invokes it in a terminal or when an automated job runs it in the background. Each phase produces a structured artifact that is checked before the next one begins, and each repository can adapt the lifecycle without forking the plugin. Product Cortex is the first instance of a broader Cortex architecture designed to host other repeatable lifecycles.

Jenny Gai and Natalie Gandolfo are the two-person product marketing team responsible for its communication phase: keeping our users, employees, and the market informed about what TRM has shipped. Before Product Cortex, their process began with a release announcement in Slack, followed by a long chain of manual research, writing, and publishing. Sometimes a release simply got missed. To improve release coverage, they built six specialized agents to carry the work forward.

• One agent scans the product release channel and creates a “pending review” row in a Notion database with the title, description, and original Slack link.
• Once Jenny or Natalie approves the row, the next agents use the upstream context to assemble GTM slides, while Byline drafts the support article in Notion. Natalie reviews and edits it before marking it “ready to publish” — the human quality gate.
• Byline sends the article to Intercom through its MCP. Updates to existing articles publish directly with no downtime; net-new articles are staged as drafts so their required visibility settings can be set before publication. Published documentation is then mirrored into purpose-built Notion databases, where Claude and other AI tools can find the same source material later.

With this new process, Jenny and Natalie have found that first-draft product release accuracy climbed from 65% to 86%. Work that once took days now takes about an hour. And the agents involved are continuously improving, because Jenny and Natalie correct the agents’ underlying skills instead of quietly fixing each output.

And most notably, no one has to carry a finished draft from one private session to another. The landing zones Jenny and Natalie established help carry the work forward and make it visible to every one (and every agent) that needs to see it.

Stop visiting the agent

A landing zone fixes where the work ends; but it doesn't change where the interaction begins. 

For example, an agent may be able to read Slack through an MCP connection. You can open Claude, point it to a message, and ask it to pull the thread. Technically, the agent can see the full conversation — but you still had to leave Slack, visit the agent, and point it back to the place where you first found the work. You carried the trigger, even if you didn't have to carry all the context.

This pattern follows how most of us use general AI assistants today. We open Claude, ChatGPT, or Gemini and ask it to use a skill. For a few minutes, the assistant puts on a hat. It becomes the researcher, analyst, or project coordinator. When the session ends, the hat comes off. The assistant goes back to being a blank starting point, and we carry the work away.

At TRM, we're now turning some of those hats into jobs — most recently with a tool called Gumloop. 

Our AI automation team regularly hosts office hours where TRMers bring questions and challenges to work through with us live. Each session produces a transcript containing useful signals about the pain points teams are encountering, the tools they need help with, and where the same questions are appearing across conversations. We used to run a skill against each transcript, one session at a time, to extract those signals and use them to shape our next enablement sessions and the content we produce.

Now, a standing Gumloop agent, Office Hours Bot, handles that workflow. It retrieves each session transcript, extracts the relevant contact and session data, records the teams we met with, identifies the tools and pain points discussed most often, and uploads everything into our Office Hours database. That database feeds a dashboard, and the agent posts updates in our AI Automation team channel about the correlations and trends emerging across sessions. Instead of leaving each transcript as an isolated artifact, the agent turns those conversations into shared knowledge that can guide what we teach and build next.

Evolving skills into teammates

We've started putting other agents directly into the Slack channels where work happens at TRM:

• Optimus Bot is the first responder in our AI automation help channel. It answers AI and automation questions from its knowledge base and escalates to our team when human intervention is required.
• TRM Security Agent reviews infrastructure pull requests, posts its findings to GitHub, and flags risky changes for the Security team.
• Office Hours Bot turns session transcripts into structured contact, team, tool, and pain-point data, updates the database that feeds our dashboard, and posts emerging trends in the AI Automation team channel.
• Botcamp Bot knows what’s planned for the current Botcamp Wednesday — our monthly day for teammates to share and exchange AI use cases and builds — and handles signups for our “Skills Showdown,” a friendly competition where teammates present skills they’ve built, and the three presenters whose skills see the greatest increase in usage post-presentation win prizes. The goal is to increase awareness and adoption of useful new skills, without teammates having to discover them by manually searching the skills marketplace.

These agents have become recognized, value-adding members of our unique operating environment. Instead of privately reviewing answers from private chats with Claude and then needing to decide what to carry forward, the managers overseeing these agents can see all of the agent’s work in context, correct it in front of the team, and adjust each agent’s permissions to maximize its impact.

For now, we’re keeping the jobs these agents own narrow. As models improve, they might take on more responsibilities, much as human employees grow into broader roles. But we don't need to wait for that future to build good communication habits now.

When agents start managing the handoff

Bringing agents into our channels closes the communication gap between humans and bots. We're also experimenting with what happens when agents use those same channels to coordinate with one another.

Right now, I'm working on a system called Project Colony. Three specialist agents report into one Slack channel each morning: 

• SlackScan looks for conversations waiting on a reply
• NotionBot checks Notion for overdue work and changes that need attention
• Newspaper reads the latest AI news and product updates so I don't have to chase them across the internet

Then a fourth agent arrives. Chief of Staff is responsible for the handoffs. It reads all three reports and replies in their respective threads when something is unclear, asking questions like, "Why does this need my attention today?" or "Can you be more specific about what changed?" Each specialist agent returns with the missing details and context. Once those exchanges are complete, Chief of Staff pulls the relevant information into a single morning brief for me.

Project Colony is still an experiment. But it gives us an early picture of what agents working inside an organizational structure could look like, instead of operating as four siloed tools. Each has a distinct job but reports into the same place, and one agent is responsible for turning all of that separate work into something another employee can use.

Invite your agents in

We keep asking how many agents a company has built. But I think the better question is how many of them can participate in the company. Can they see the context they need? Do they know where to put their work? Can the next person or agent tell what changed? Can the team correct them, ask a follow-up question, and trust that the result will remain visible after the session closes?

Closing the communication gap lets agents carry their own work into the company instead of asking people to act as couriers. Their managers can see what happened, correct the work, and decide what the agent should do next.

I keep coming back to how strange and exciting this all is. AI is moving from a tool we visit to a set of digital coworkers we can name, assign, teach, and bring into the room. It’s still early days. We'll learn where these agents belong, and I'm sure we'll find plenty of places where they don't. But I'm excited to see what they accomplish once they truly work with us.