LangChain shares five building blocks of its internal 'company harness'

Three agents, one recipe

In a blog post by Harrison Chase and Caspar Broekhuizen, LangChain says its internal agents "have completely changed how those teams work", but that they were not easy to get right. The company says it spent a lot of time on the problems that come with a multiplayer harness, meaning one shared by many people rather than a single user.

LangChain lists three main internal agents:

• GTM Agent: a proactive, always-on agent for go-to-market work. It monitors and responds to emails and new qualified leads, sends daily briefs, answers questions about accounts and can run outbound motions.
• OpenSWE: the engineering agent. It can work on and draft pull requests, and it runs code review over all PRs.
• Content Studio: the marketing agent. It drafts blogs, images, PowerPoints and videos in the company's style and with knowledge of its positioning.

All three are built the same way, which LangChain presents as a general recipe for company harnesses. The five shared primitives are: living where people already work, knowing who is asking, having scoped memory, running code in a sandbox that can reach authenticated services, and running many tasks on a schedule.

User experience and identity

For LangChain the workplace is Slack. Each agent has its own Slack app and can be messaged directly or tagged in a channel. The company notes that working in channels lets others see how colleagues use the agents. It also added a way for an agent to "breakout" into its own thread, so that pulling an agent into a human conversation does not clutter or distract from it.

Some tasks do not suit Slack. Reviewing a large backlog of emails drafted by GTM Agent is one example, and for cases like that the team built a custom UI.

Identity was, in the authors' words, the thorniest problem: when an agent acts, on whose behalf does it do so? LangChain describes two common approaches. With on-behalf-of, the agent acts for the user who invoked it. With fixed credentials, such as a service account, it uses the same access no matter who calls it. The company mixes both:

• OpenSWE: acts as the user when messaged, for example opening PRs under that person's GitHub handle. In the background, such as during code review, it acts with its own identity as a GitHub app.
• GTM Agent: uses a fixed identity for tools like Salesforce, so not everyone has to log in. Email acts on behalf of the invoking user and is available only in DMs, not in shared channels.
• Content Studio: acts on behalf of the user for tools like Notion, but uses the company Twitter account credentials for Twitter. Only whitelisted users can run certain operations, so not everyone can post, and some may only read or draft.

Memory, sandboxes and scheduled runs

All agents have two tiers of memory: global memory that applies to all users, and user memory that applies only to a specific user. The agents decide which facts go into which tier. LangChain calls this probably the least explored area so far and says it has a lot of work planned there.

All three agents can write and execute code. They run outside the sandbox but connect to it to execute code there, each with a slightly different base image and dependencies. OpenSWE, the most coding-focused agent, chooses which base image to start depending on the channel and user. The agents use the secret proxy in LangSmith Sandboxes so they can reach services safely from inside the sandbox.

A large percentage of runs are scheduled or triggered by events rather than started by a person. Some are set up by developers: OpenSWE listens for new PRs and reviews them. Others come from user requests: the author asked GTM Agent for a daily brief, and the agent created its own cron job to deliver it.

What it means for teams building agents

LangChain says the infrastructure for channels, crons, sandboxes, memory and identity is provided by Managed Deep Agents, while leaving enough flexibility to customize agent behavior. The company points readers to a quickstart for trying it.

For teams planning shared, company-wide agents, the post is a practical checklist based on LangChain's own experience. It suggests that identity rules, such as which tools run as the user and which use a fixed account, need to be decided per tool, and that scheduled and background work is a major share of what such agents do. The details reflect one company's internal setup, as reported by LangChain itself.