LangChain Company Harness: 5 Parts Internal Agents Need

LangChain built internal agents for three different teams, sales, marketing and engineering, and all of them ended up needing the same five parts. For platform teams asked to give every department its own agent, that is the useful finding: the shared plumbing around the model matters more than any one agent, and identity, which LangChain calls the hardest problem, is where the work starts.

The Framework

In a post on the five components of a company harness, Harrison Chase and Caspar Broekhuizen describe three agents LangChain runs internally:

• GTM Agent, an always-on agent that monitors email and leads, sends daily briefs, answers account questions and runs outbound campaigns.
• OpenSWE, an engineering agent that drafts pull requests and reviews all of them.
• Content Studio, a marketing agent that drafts blogs, images, slides and videos in the company’s style.

These are what LangChain calls multiplayer agents: many people use them, in shared spaces. All three run on Managed Deep Agents, which sits on the open-source Deep Agents harness and supplies channels, schedules, sandboxes, memory and identity. The five components are the parts every team needed.

1. Put the Agent Where People Already Work

At LangChain that place is Slack. Each agent has its own Slack app and can be messaged directly or tagged in a channel, and it can break out of a busy channel into its own thread. Chat didn’t fit every job, though. Reviewing a large backlog of emails worked better in a custom interface.

2. Decide Whose Identity Each Action Uses

An agent can act on behalf of the person who invoked it, or with fixed credentials such as a service account or app. LangChain’s agents mix both, tool by tool. OpenSWE acts as the user in chat but as its GitHub app in background runs. GTM Agent only allows its email tools in direct messages. Content Studio limits who can perform certain operations on the company Twitter account. The identity documentation covers how the platform handles the split.

3. Scope Memory Globally and Per User

Memory has two tiers, global and per user, and the agent decides which tier each fact belongs in. The authors call memory the least-explored of the five so far. Stack Archive’s coverage of how Deep Agents handles context rot looks at the same harness from the angle of long-running context.

4. Run Code in a Sandbox That Can Reach Services

The agents run outside the sandbox and execute code inside it, with different base images for different agents. To call authenticated services from inside the sandbox, they use LangSmith’s secret proxy.

5. Let Agents Run Without Being Asked

Much of the agents’ work is scheduled or triggered by events rather than started by a person. Some schedules are set by developers, such as OpenSWE reviewing new pull requests. Others are set by users: GTM Agent can create its own cron job for a daily brief when someone asks.

Where It Doesn’t Apply

This is one company describing its own agents, built on its own commercial platform, so the five components line up neatly with what Managed Deep Agents offers. Teams on other stacks can still use it as a checklist, but should expect to assemble the same parts from separate tools. The post also describes what was built rather than measuring it: it gives no figures for usage, accuracy or time saved. And by the authors’ own account, memory is still the least settled part.

Source: LangChain Blog

Content created with AI assistance and reviewed for accuracy.