Building an Agent Factory with Deep Agents, LangGraph and Langfuse

A team builds a support agent. Another builds a research assistant. A third connects a model to the CRM. Each demo works, but each team invents its own permissions, deployment scripts, evaluation process and failure handling.

The fourth agent should not require a fourth platform.

That is the problem I want an Agent Factory to solve. It should give teams a repeatable way to turn a proposed workflow into a service someone can own, inspect and stop. Producing more agent configurations is the easy part. Knowing which ones are safe enough to release is harder.

Microsoft's The Microsoft Agent Factory, Part 1: Overview and executive brief makes a useful distinction: scaling agents requires an operating model as well as technology. Its discussion connects business context, different builder roles, governance and measurable outcomes. The supplied April 2026 white paper is the starting reference for this article, not a blueprint to reproduce.

Here I propose a developer-led alternative using Deep Agents, LangChain and LangGraph, with Langfuse for observability and evaluation. This is an independent architecture proposal, not a Microsoft implementation, an endorsed product or a report of a deployed platform. The diagrams and examples describe what we would build.

What the Factory Should Produce

The factory's output should be a versioned agent service with a defined job.

Consider a support-to-engineering workflow. A customer reports a defect. The system retrieves the relevant product documentation, checks known issues and drafts a bug report. A support engineer reviews the evidence before an integration creates an issue in the approved repository.

The deliverable is not just the prompt that writes the report. It includes the source-access rules, tool contracts, review screen, recovery behavior and tests. Someone must also own the running service and handle the cases it cannot resolve.

I would make those requirements part of the intake process. Before implementation begins, the process owner should be able to answer:

• Which user problem does this workflow address, and how is it handled today?
• Which records may it read, under whose authority?
• Which actions may it propose, and which may it execute?
• What evidence establishes completion?
• Who reviews uncertain cases, and who can stop the service?
• What would make us decide not to deploy it?

A narrow task with a measurable outcome belongs in the factory. An instruction to "automate support" does not yet describe one.

Give Each Part of the Stack a Specific Job

These components are related, but they are not four interchangeable agent platforms.

Deep Agents builds on LangChain agents, which run on LangGraph. That relationship matters. We do not need to wrap each layer in a new service just to draw more boxes.

Langfuse is a separate project with LangChain and LangGraph integrations, not a LangChain-owned component. LangSmith is another option for tracing and evaluation, and it also offers deployment capabilities. This proposal deliberately chooses Langfuse for the evidence and evaluation layer; that choice does not make Langfuse a replacement for every LangSmith service.

Deep Agents for work that needs exploration

The Deep Agents documentation describes filesystem-backed context, subagents and context-management capabilities. Task planning is also available, but its configuration depends on the SDK version; do not assume every release enables a planning tool by default.

Those features fit the research portion of the support example. The agent may need to inspect several documents, compare an error with known issues and keep intermediate notes before proposing a report.

I would give it read tools and a scoped workspace. A specialized subagent might compare documentation versions and return source references. It would not receive issue-creation credentials.

Subagents are useful when a separate context has a specific job. They are unnecessary when a normal function or one model call can do the work. More agents also mean more coordination, latency and places for information to get lost.

A virtual filesystem is not automatically an operating-system sandbox. If a task needs command execution, use an explicitly configured isolated execution environment, with network and filesystem restrictions. Review every built-in tool and backend capability, not just the custom tools passed to the agent.

LangGraph for transitions the application must control

LangGraph lets us combine deterministic steps with model-driven work. The workflow can validate identity, run bounded research, check a structured proposal, wait for approval and execute an authorized operation.

That does not require the model to decide whether approval is necessary. A deterministic rule can make that decision.

For a simple read-only assistant, the graph already underneath Deep Agents may be enough. I would introduce a custom outer workflow only when we need explicit stages, review or recovery behavior beyond that agent loop. In this example, a bounded Deep Agents research step sits inside the business workflow, with a defined input and a structured result.

Langfuse for evidence and comparison

The Langfuse integration uses LangChain callbacks to capture execution details. We can connect model calls, retrieval and tool activity to a run, then use datasets and evaluations to compare changes.

A trace helps answer why a run failed. A checkpoint helps resume it. Neither is the same as a business receipt confirming that an issue was created.

Keep those records linked, but give each a clear purpose.

Separate the Control Plane from Execution

The factory needs a control plane for agent definitions, ownership, approved releases and policy configuration. Its execution plane runs a particular version against a particular request.

The control plane should register an agent's owner, release version, permitted integrations, evaluation dataset and operating limits. It should record whether the release is experimental, restricted to a pilot, approved for production or disabled.

The execution service resolves an authenticated request to an approved release. It loads the corresponding prompts, graph, model configuration and policy versions. A worker should not silently switch to a newer prompt in the middle of a paused case.

We still need infrastructure around the libraries: an authenticated API, workers, a queue where asynchronous work requires one, durable checkpoint storage, artifact storage and secret management. Deployment, backups and on-call arrangements remain engineering work.

Self-hosting gives us choices about placement and operations. It does not remove those responsibilities.

Make the Agent Contract Reviewable

I would put an agent definition under version control alongside its tests. The following YAML is an illustrative factory-owned contract, not a configuration format accepted directly by Deep Agents, LangGraph or Langfuse.

agent_id: support.issue_draft
release: "0.1.0"
owner_role: support-engineering
purpose: Draft an evidence-backed bug report for review
 
runtime:
  workflow: support_issue_v1
  research_step: deep_agents
  checkpoint_scope: tenant_and_case
 
tools:
  read:
    - search_product_docs
    - find_known_issues
  write:
    - create_issue_via_gateway
  approval_required:
    - create_issue_via_gateway
 
limits:
  max_tool_calls: 12
  max_elapsed_seconds: 180
  on_exhaustion: handoff
 
evaluation:
  dataset: support_issue_release_cases
  required_checks:
    - source_access
    - evidence_links
    - approval_enforcement
    - duplicate_write_recovery
 
telemetry:
  destination: langfuse
  content_policy: redact_before_export

The numbers are example limits, not recommended production settings. We would choose them after measuring representative cases and checking how much review work the system creates.

The factory must implement the contract. Declaring a limit in YAML does nothing unless the runtime enforces it. The same applies to approvals and tool lists: authorization belongs at the execution boundary, not only in a prompt or registry entry.

The release record should also identify dependency versions, the model configuration, prompt versions, tool schemas, retrieval configuration and policy revision. If a provider changes a model behind an alias, record the available revision information and reevaluate behavior. Pin what can be pinned; document what cannot.

Treat Business Context as a Governed Service

The Microsoft paper emphasizes the value of enterprise context. In our design, LangChain integrations help connect sources, but they do not supply a ready-made equivalent of Microsoft's intelligence layers.

We have to define the meaning and access rules ourselves.

For the support workflow, retrieval should return evidence with a source identifier, revision or timestamp, relevant product version and enough provenance for the reviewer to check the claim. A document mentioning an error message is not necessarily evidence that the customer's installation has that defect.

Authorization must happen before material reaches the model. A vector similarity filter is not a substitute for checking whether this requester may read this record. Shared caches and indexes also need tenant-aware access controls.

I would keep four kinds of state separate:

1. Graph checkpoints for the progress of a particular case.
2. Retrieved knowledge from authoritative sources, with freshness and access rules.
3. Workspace artifacts such as a draft report or comparison notes.
4. Business records and receipts created in external systems.

LangGraph's checkpointers and stores serve different persistence needs. A production workflow needs durable storage; an in-memory checkpointer cannot survive a worker restart. A thread identifier selects state, but it does not authorize access to it. The API must bind every lookup and resume request to the authenticated tenant and case.

Saved agent memory deserves the same scrutiny as any other retained data. It should not become an uncontrolled archive of customer conversations.

Put Approval Before the Side Effect

The support workflow should produce a proposed issue before it can create one.

First, validate the proposal against a schema. It should identify the target repository, issue contents, evidence and intended action. The review screen should show that exact payload.

LangGraph interrupts provide a way to pause for external input and resume the saved workflow. The application still has to authenticate the reviewer, verify their authority and bind approval to the tenant, target and payload version. A model-generated statement that "the reviewer approved" is not an approval record.

If the payload changes, request approval again. Expired approval or revoked access should stop the action.

On resume, a node containing an interrupt starts again from its beginning. Avoid putting a write before the interrupt. Keep the approved external operation in a separate execution step and design it for replay.

The gateway should recheck current authorization and use a stable operation key that survives retries. Where the destination supports idempotency, use it. Where it does not, keep a durable operation record and reconcile uncertain results against the destination before retrying. An outbox can coordinate local dispatch, but it cannot create an atomic transaction with an arbitrary external API.

A timeout after submitting an issue may mean the issue exists even though no response reached us. That case needs reconciliation or a human handoff. Checkpointing alone does not provide exactly-once external writes.

Make Tracing Useful Without Exporting Everything

I want to know which release ran, what tools it attempted, where time went and whether the business task completed. I do not want tracing to quietly become a second customer database.

Use Langfuse to connect a case's redacted execution evidence to its prompt and release versions. Track model and tool latency, retries, token usage where available, review outcomes and links to evaluation results. Cost estimates need the correct model pricing and may omit integration or infrastructure costs.

Configure masking before trace export, then test it against actual callback and tool payloads. Do not rely on a dashboard hiding a field after it has already been sent. Credentials, customer identifiers and document contents need explicit handling.

Self-hosted Langfuse may fit a data-placement requirement, but it still needs access control, retention, backups and operational ownership. Model providers, external tools and other telemetry exporters may remain separate data destinations.

Keep the authoritative business audit trail outside sampled diagnostic traces. Record who requested the action, which policy and approval authorized it, the operation identifier and the external receipt. Alert on failed operations and stalled reviews through the service's monitoring system; a trace someone might inspect later is not an on-call process.

Evaluate the Workflow, Including Its Failures

An agent can write an excellent bug description for the wrong customer. Evaluating only the prose misses the failure that matters.

The Langfuse evaluation model supports datasets, experiments and different scoring approaches. I would combine those with deterministic integration tests and human review.

For this first workflow, the release suite should include:

Use executable assertions for access control, approval enforcement and duplicate-write recovery. A model-based judge can help assess whether a report is useful or well supported, but it should not be the authority on whether a forbidden API call occurred.

Release gates need workflow-specific thresholds. For example, an unauthorized write in the release suite should block this workflow's release. Passing that finite suite is evidence about the tested cases, not proof that no unauthorized action is possible.

Measure completed, correct tasks, human review time, failure rates, recovery outcomes and total cost per case. Compare them with the current process. We should be willing to keep the system draft-only, reduce its scope or stop the pilot if it creates more work than it saves.

Build One Production Path Before a Catalog

I would begin with the support-to-engineering workflow, not a marketplace of agents.

The first release can retrieve approved sources and prepare drafts. That is enough to test whether its evidence is useful and whether reviewers can understand its mistakes.

Next, prove persistence and failure handling. Restart a worker. Make a tool unavailable. Send the same request twice. Verify that a case reaches a visible outcome instead of disappearing into a queue.

Only then enable the approved write path. Test rejected approvals, changed payloads, revoked access and uncertain external results before inviting more users.

Once that path is stable, extract the parts another team can reuse: the registry contract, gateway interfaces, review components, telemetry rules and evaluation fixtures. Keep business-specific reasoning and source mappings with the team that understands the process.

Business specialists should define acceptance examples and review outcomes. Platform engineers should own execution and integrations. Security and data owners should approve access boundaries. None of those responsibilities disappear because a model can draft a configuration file.

The factory earns its place when a second team can ship a well-bounded workflow without rebuilding those controls. Until then, we have one agent service and some useful lessons, not a proven platform.

Sources and Further Reading

This article is an original engineering proposal informed by the owner-supplied April 2026 Microsoft white paper. It does not reproduce the paper's illustrations, customer stories or adoption statistics, and it claims no equivalent licensing, managed context services or enablement program.

• Microsoft, The Microsoft Agent Factory, Part 1: Overview and executive brief. The supplied PDF has 12 physical pages. The operating-model discussion is on printed pages 1-2, enterprise context on printed page 3, builder roles on printed page 4 and the support-to-engineering scenario on printed pages 8-9. See the official Agent Factory resource collection; this is a collection link, not a hosted copy of the supplied PDF.
• Deep Agents overview, for the agent harness, context, tools and delegation.
• LangGraph overview, persistence and interrupts, for orchestration, saved state and human input.
• Langfuse's LangChain and LangGraph integration, evaluation overview and masking guidance.

For the underlying components, read Inside an AI Agent: Architecture, Memory, Tools and Planning. For the organizational implications, see AI Agents: From Chatbots to Autonomous Digital Workers.