Company Agents in Production: First Issue a Badge, Then Talk About Intelligence

Sydney Runkle broke down the differences between company agents and coding agents on X into several dimensions: where they work, identity, memory, sandboxes, and scheduling. Harrison Chase then wrote up how LangChain built three internal agents. The three agents are GTM Agent, OpenSWE, and Content Studio. They all work inside Slack, but the engineering problems behind them go far beyond wiring up a model.

Giving an agent a badge is harder than giving it an avatar

All the agents live in Slack. Each has its own Slack app; you can DM it or @-mention it in a channel. Using them in channels has one advantage: other people can see how you use them. LangChain added a breakout: when humans are in the middle of a conversation and want the agent to chime in or do work, it gets its own thread so it doesn't pollute the original conversation. Scenarios like an email backlog are not well suited to digging through messages in Slack, so they built a custom UI.

Identity is the hardest part. There are two common approaches in the industry: on-behalf-of, where the agent acts on behalf of the caller; and fixed credentials, where the agent uses a set of service accounts. OpenSWE opens a PR in a DM using your GitHub handle, then switches to a GitHub app identity for background code review. GTM Agent uses a fixed identity for Salesforce and the caller's identity for email tools, and only exposes email tools in DMs, not in channels. Content Studio represents the user for Notion, uses fixed credentials for the company Twitter account, and only allowlisted users can trigger certain actions—not everyone can post to Twitter.

A comment asked: are OBO and first-party identities configured per tool, or is there a fallback when the user hasn't connected the service? The source material doesn't elaborate on this question, but it determines whether the permission model can be audited. Another comment was more direct: with scheduling plus OBO, an agent can send emails or delete things when no one is watching—who signs off? So approvals have to be on the checklist.

The engineering gates for coding agents are relatively clear: PRs, code review, and sandboxes. Company agents directly touch email, Salesforce, and the company Twitter account, and their actions are harder to roll back.

Memory must be visible and revocable

All the agents have two layers of memory: global memory and user memory. The agent decides which facts go into which layer. Harrison says this is currently the least explored part. The diagram separates short-term working memory from long-term memory, and long-term memory is further divided into semantic, episodic, and procedural. For ordinary users, you can think of it this way: it has to remember your preferences and also remember team consensus, but the two must not be mixed up.

Agent memory structure: short-term working memory and long-term memory

A comment added a key point: memory also needs visibility. After the agent decides what to remember, humans need to be able to see every write and undo incorrect facts; otherwise one mistake will stick around forever. That judgment is closer to the production problem than memory capacity is.

Sandboxes and scheduling turn agents into unattended coworkers

All three agents can write and execute code. Their runtime processes sit outside the sandbox and connect into it when executing code, and each has a different base image. OpenSWE chooses the image based on the channel and user. They use LangSmith Sandboxes' secret proxy so agents can securely connect to services from inside the sandbox.

A larger share of runs are triggered by schedules or background events; people rarely click directly. OpenSWE listens for PRs and reviews new ones. GTM Agent's daily brief was requested by a user, but the agent created the cron itself. Someone in the comments said schedules are the most-used feature: run a few routines in the morning, then wake up and just look at what's left. That's also where the problem lies: when a self-created cron fires, the person who originally asked for it isn't there—whose identity does it use? Should the audit log record both the user and the agent? When a fixed-identity agent is invoked by different users, how do you narrow permissions? The answers to these questions live in the harness; model parameters can't solve them.

Monitoring is not control, and knowledge must be traceable

The EKOS article raises a harder security problem: if the system being monitored can change the monitoring and alerting, then no amount of logging is reliable. Monitoring, alerting, and execution are different responsibilities. An agent should not have unilateral authority to modify the boundaries that constrain it.

The knowledge layer is the same. Enterprise information is scattered across code, SQL schemas, configuration, documentation, transformation pipelines, and repository history. Vector retrieval returns a passage of text; that is not the same as providing entity relationships, dependencies, source evidence, and processing history. What EKOS does is compile fragmented evidence into a structured, connected, traceable knowledge graph that preserves file paths and line numbers and exposes it to agents through MCP. It does not solve runtime permissions; runtime security has to be handled independently. The two are complementary.

Don't mistake Content Studio's jokes for production

Content Studio is a marketing agent that can draft blog posts, images, slides, and videos in the company's style and positioning. Someone posted a screenshot saying it put Harrison's face on a TIME cover and emphasized that it was traceable. It's funny, and it also illustrates the capability boundary: it can edit images and write copy, but posting to Twitter requires being on the allowlist. The real risk with company agents is that they use credentials to touch real systems.

Screenshot of a post related to Content Studio

LangChain packages these capabilities into Managed Deep Agents, built on the open-source Deep Agents harness, which provides channels, cron, sandboxes, memory, and identity. Looking at it all together, the recipe for company agents isn't mysterious: live where people work, know who is asking, remember things but allow undo, run code in a sandbox, trigger a large share of tasks on a schedule, and keep approvals and auditing independent of the agent.

Giving an agent a Slack avatar is easy. Giving it a badge, permissions, an on-call schedule, and an operation log—that's where company agents actually start to land in production.