LangChain summarizes the five components of a company-level Agent harness

Company Harness Five-Piece Set: Turning company-level Agents into infrastructure for multi-person collaboration

@LangChain, drawing on its own three internal Agent sets for GTM / engineering / marketing, distilled the five common foundations of a "company-level harness": living in the collaboration entry points people already use, identity (OBO vs. service accounts) implemented per tool, global/user two-tier memory, running code inside a sandbox with access to authenticated services via a secret proxy, and a large share of tasks being ambient agents triggered by schedules or events—all built on Managed Deep Agents (layered on top of the open-source Deep Agents harness). https://t.co/Iorrbv51uY

Background: three internal Agent sets, one shared recipe LangChain wrote this article because it has internal Agents running in marketing, sales, and engineering, and after hitting many pitfalls with a "harness shared by multiple people," the teams converged on the same set of primitives. Three examples used to ground the discussion: · GTM Agent: an always-on growth assistant that watches email and qualified leads, sends daily briefs, answers account questions, and runs outbound. · OpenSWE: an engineering Agent that can modify code, draft PRs, and do code review on all PRs. · Content Studio: a marketing Agent that drafts blogs, images, PPTs, videos, and other assets in the company's style and positioning.

LangChain believes this is not just an internal special case but a general recipe for a company harness.

Problem one: experience—where people work is where the Agent lives All three Agent sets use Slack as the entry point: each has its own independent Slack App, and can be DM'd or @-mentioned in channels. The benefit of channel collaboration is that colleagues can see how others use it.

One specific product detail: breakout (splitting out a sub-thread). When a human discussion is in full swing and someone wants to pull the Agent in to do work or give input, running it directly in the original thread would pollute the conversation; so they made it "one-click split into a separate thread in the channel," separating Agent work from interpersonal discussion.

They also acknowledge Slack is not a cure-all: for example, when the GTM Agent reviews emails pending send, a few can be clicked in Slack, but once a backlog builds up it is hard to keep up with; for this kind of experience they eventually added a custom UI.

Problem two: identity—the hardest, most painful piece The core question: when an Agent takes action, who does it represent? The industry commonly has two paths: 1. On-behalf-of (OBO): act as the user who invoked the Agent. 2. Fixed credentials: no matter who invokes it, use the same set of credentials (such as a service account).

They split this by Agent, and even by tool (the article points to the identity / connections docs for Managed Deep Agents): · OpenSWE: when you message it, it acts OBO you (for example, opening a PR with your GitHub handle); when running in the background (such as code review), it uses its own identity (GitHub App). · GTM Agent: Salesforce and the like use a fixed identity (no need for everyone to log in); email and the like act OBO the invoker—and such tools are only available in DMs, disabled in shared channels, to avoid sending mail on someone's behalf in public. · Content Studio: Notion and the like use OBO; posting to Twitter and the like uses fixed company account credentials, with a whitelist for high-risk operations (for example, not everyone can tweet; some may only be able to read/draft).

Problem three: memory—global layer + user layer All Agents have two tiers of memory: global memory (effective for all users) and user memory (only for that user). The Agent itself decides which facts go into which layer. LangChain considers this the least explored piece so far and plans to invest heavily in it going forward.

Problem four: code execution—process outside, code inside the sandbox All three can write and run code. The pattern is consistent: the Agent itself runs outside the sandbox and connects to the sandbox to execute inside; each has a slightly different base image / dependencies. OpenSWE also intelligently chooses which image to spin up based on channel/user. The security surface relies on the secret proxy of LangSmith Sandboxes: letting code inside the sandbox securely connect to services that require authentication (the article links to docs such as "adding a sandbox to Managed Deep Agents").

Problem five: schedules and events—many runs are not human-triggered A very large proportion of runs are triggered by schedules or background events rather than invoked by a user on the spot (the article emphasizes ambient agents). Two sources: · Developer-preset: for example, OpenSWE listens for new PRs and automatically reviews them. · User-created after dictating: for example, LangChain had the GTM Agent give a daily brief, and it created its own cron.

Closing: Managed Deep Agents The aforementioned channels, cron, sandbox, memory, and identity are all provided by Managed Deep Agents (layered on top of the open-source Deep Agents harness), while preserving room to customize Agent behavior; the end of the article points to the quickstart.