Build a Fraud Review Agent with MongoDB Atlas and Claude Managed Agents

Claude Managed Agents lets you run Anthropic's Claude as a fully hosted agent, without standing up your own inference or orchestration infrastructure. Pairing Claude Managed Agents with MongoDB Atlas gives your agents fast, secure access to operational and vector data right where it lives, so you can ship agentic workflows without gluing together separate retrieval and hosting layers.

This tutorial shows you how to build a human-in-the-loop fraud review agent that runs on Anthropic’s Claude Managed Agents and uses MongoDB Atlas as its retrieval engine, graph store, and system of record. The agent reviews flagged payment transactions, pulls precedent and relationship signals out of Atlas, pauses for a human reviewer on the risky cases, and writes an immutable verdict back to the same cluster it read from.

By the end of the tutorial, you’ll be able to wire a credential-safe MongoDB data path into a managed agent, run four retrieval patterns against a single collection, gate risky decisions behind a durable human pause, and make one cluster the agent's audit backbone.

Most agent stacks assemble this out of three or four systems: a vector database for semantic search, a separate engine for keyword matching, a graph store for relationships, and an operational database for the records themselves. Every seam between them adds an integration to maintain and a credential to manage, and adds one more place the agent's view of the world can drift out of sync. MongoDB Atlas runs all four access patterns (vector, full-text, hybrid, and graph) over the same documents in the same cluster, reached through one pymongo connection. Fraud review exercises all of it at once: a reviewer needs semantic precedent, an exact-match lookup, and network traversal on the same case, and the decision has to land somewhere that an auditor can read later.

What each side handles

Claude Managed Agents and MongoDB Atlas do different jobs here, and keeping the boundary between them clear is what makes the pattern safe to run.

Managed Agents runs the agent loop on Anthropic's infrastructure: the model's reasoning, the sequence of tool calls, and the native human-in-the-loop pause. Your process controls the data path. When the agent decides it needs data, it calls a custom tool; the session goes idle with stop_reason: requires_action; your code runs the pymongo query host-side and posts the result back; the session resumes. The MongoDB connection string stays in your environment and your handler functions. It never enters the agent context or the sandbox.

MongoDB here is your operational data store, retrieval engine, and system of record—the data your application controls. That is a distinct role from the memory features that Managed Agents manages natively on the platform. The two are complementary: Managed Agents remembers how it has interacted; MongoDB Atlas holds the transactions, precedents, decisions, and audit trail.

The credential boundary described above is the property of the recommended integration path (the notebook calls it Path A, the host-side custom tool). Two other connection paths exist, and the notebook compares them, but the host-side custom tool is the one that keeps the secret on your side, which is why it is the default for anything touching production data.

Figure 1. The division of labor between Claude Managed Agents and MongoDB Atlas.

Connect to MongoDB without handing over the credentials

The wiring has two halves: custom tools declared on the agent, and a host-side loop that services their calls. A tool is a JSON schema that the agent can call, a Python function that runs the query host-side, and one line registering the two.

Here is get_transaction end-to-end; the other five tools follow the same shape.

The schema is all the agent sees. The function runs in your own process, so the coll.find_one and the connection behind it never reach the sandbox.

The second half is the loop that dispatches each call. Every agent.custom_tool_use event names a tool and its input, and the session then idles with stop_reason: requires_action until you answer. You look the tool up in HANDLERS, run it host-side, and post the result back:

MONGO_URI is read once, on your side, and never travels to Anthropic. A free M0 Atlas cluster is enough to run everything in this tutorial.

One collection, four retrieval patterns

The agent's evidence comes from four retrieval patterns, each a plain aggregation pipeline against the same transactions collection. In fraud review, they answer different questions:

Figure 2. One collection, four retrieval patterns.

Hybrid is the production default. $rankFusion (available in MongoDB 8.0 and later, including free M0 clusters) runs a vector branch and a lexical branch and fuses them by reciprocal rank in a single server-side aggregation:

Both branches read the same documents and the same embedding field. There is no vector database to sync against a separate search index, because they are one index surface on one collection. To weight semantic over lexical, add a combination.weights clause; the default treats both branches evenly. The notebook ships precomputed vectors and passes qvec in, so it runs without an embedding-provider key. In production, you can use Atlas Automated Embedding instead: select a Voyage AI model when you configure the vector index, and Atlas generates the embeddings and keeps them in sync as documents change. No embedding pipeline to run alongside the cluster.

Graph traversal is the pattern most agent tutorials skip, and it is the one a financial-crime reviewer will look for. $graphLookup walks the sender-to-recipient chain out of a seed account, following each recipient into the next transaction's sender:

A helper reads the resulting chain for the signals that matter: money that flows in a circle back to the seed account, layering (many small transfers), and the size of the network. Relationship signals are orthogonal to content similarity: a mule chain can be five plausible-looking individual payments that each pass every similarity check on their own, which is why $vectorSearch and $search find similar transactions while $graphLookup finds connected ones.

The agent: Verify, retrieve, decide, escalate

Each of those pipelines becomes a custom tool. The agent also gets a hard gate at the front of the flow: before any behavioral analysis, it verifies a cryptographically signed authorization mandate (the open AP2 protocol) and rejects immediately on an invalid signature, an unmet constraint, or a double-spend. The system prompt fixes the order and the escalation rules:

The escalation rules encode real financial crime triggers. A deposit of $4,950 sits just under the $5,000 currency-transaction-report threshold—the classic structuring signature. A $50,000 wire may be legitimate and still requires a human under policy. A ring signal from $graphLookup is not something to auto-approve. In each of those cases, the agent calls escalate instead of deciding.

Figure 3. The fraud-review flow.

That escalation runs through Managed Agents' native human pause. escalate is a custom tool like the others, but its handler routes to a human reviewer rather than to pymongo. The session idles at requires_action and holds—the state lives on Anthropic's side, so it survives whatever your process is doing. This is a durable gate, not a fragile input() call blocking a script. When the human responds, the agent records the final decision with escalated=true and both verdicts preserved: what it recommended, and what the human decided.

With the tools and the system prompt in place, create the agent, open a session, and hand the event stream to the gate loop:

In a representative run over five flagged transactions, the agent clears the two clear-cut cases on its own and escalates the structuring, high-value, and ring cases to a human, servicing on the order of two dozen tool calls along the way. Exact counts vary by model and run, though the sequence of steps is the same each time.

One cluster as the system of record and audit trail

Everything the agent did is durable in the same cluster it retrieved from. Four collections carry the write side:

• transactions: the operational record; each case advances from pending to approved or rejected.

• transaction_decisions: append-only verdicts with reasoning, confidence, and risk factors.

• audit_events: an append-only trail; escalations record both the agent's recommendation and the human's call.

• mandate_receipts: AP2 receipts that power double-spend detection on later runs.

There is no separate audit system, event bus, or second database to reconcile against. record_decision makes those writes in a single host-side handler: it inserts the immutable verdict, appends the matching audit event, and advances the case from pending to a decided status.

(build_decision_doc and build_audit_event shape the persisted documents; both live in the notebook's helper module.)

Reading the same case back shows the operational status, the decision record, and the audit trail in one place:

For a fraud-review workflow, the audit trail is the same set of writes the agent already makes, sitting in the same cluster the examiner queries. Retrieving what was decided, by whom, and against which precedent is an ordinary query.

Run it yourself

The full runnable notebook is in the Claude Cookbooks: managed_agents/Claude Managed Agents_with_mongodb_atlas.ipynb. It ships the seed data with precomputed embeddings, the AP2 signing helpers, the index setup, and all six tools. A free M0 cluster and an Anthropic API key run everything, because the seed ships precomputed vectors; no embedding-provider key is needed to try it. The default model is claude-haiku-4-5, overridable through COOKBOOK_MODEL.

If you are new to the human-in-the-loop custom-tool gate, start with Managed Agents_gate_human_in_the_loop.ipynb—it teaches the pause pattern this notebook builds on. When you are ready to move past a single-process streaming loop, Managed Agents_operate_in_production.ipynb covers webhooks for session status, MCP toolsets, and vault integration.

The same shape carries to other domains. Swap the collection and the tool set for your own, keep the credential on your side, and the retrieval, the human gate, and the audit trail come with it.