---
title: "Code Mode Without the Interpreter: Agents That Write Aggregation Pipelines"
description: "Fixed-tool document agents suffer multiple round trips and context window bloat because each call returns raw data, and cross-document relationships require pulling all files into the context. The author’s solution lets the agent write a MongoDB aggregation pipeline instead of arbitrary code, avoiding the security risks of a code interpreter. A handler validates the pipeline, prepends a tenancy filter, and executes it server-side, returning only the reshaped result. The agent uses a two-pass approach, often computing booleans or concatenating fields with $addFields so comparisons happen in the database. Limitations include regex not being semantic search and $limit silently truncating results, but the bounded language of nine permitted stages improves both safety and accuracy."
---

# Code Mode Without the Interpreter: Agents That Write Aggregation Pipelines

[MongoDB](https://yomu.fyi/company/mongodb) · Oct 7, 2026

**Type:** Problem & solution

## Summary

Fixed-tool document agents suffer multiple round trips and context window bloat because each call returns raw data, and cross-document relationships require pulling all files into the context. The author’s solution lets the agent write a MongoDB aggregation pipeline instead of arbitrary code, avoiding the security risks of a code interpreter. A handler validates the pipeline, prepends a tenancy filter, and executes it server-side, returning only the reshaped result. The agent uses a two-pass approach, often computing booleans or concatenating fields with $addFields so comparisons happen in the database. Limitations include regex not being semantic search and $limit silently truncating results, but the bounded language of nine permitted stages improves both safety and accuracy.

## Context

The post describes the challenges of using fixed MCP tools for a document agent that answers questions about contracts. These tools cause multiple round trips and context window bloat, and cannot handle cross-document relationships without pulling all documents into the context. The author presents a solution where the agent writes a MongoDB aggregation pipeline instead of arbitrary code, avoiding the security risks of a code interpreter. The approach has been in production for five months and is also reused for observability.

## Approach / What changed

The agent authors a MongoDB aggregation pipeline. A handler validates the pipeline, prepends a tenancy filter, executes it server-side against the workspace’s documents, and returns only the reshaped result. The permitted stages are $match, $unwind, $project, $group, $sort, $limit, $skip, $count, and $addFields. Stages like $out and $merge are rejected, making the tool read-only. The agent uses a two-pass approach: a first pipeline to survey the data, then a targeted pipeline that often uses $addFields to compute booleans or concatenate fields. This collapses multiple round trips into one and filters data at the source.

## Takeaways

- Fixed tools for document agents cause context window bloat because each tool call returns raw data, and cross-document relationships require pulling all documents into the context, making the approach unscalable.
- Letting the agent write a MongoDB aggregation pipeline instead of arbitrary code collapses multiple round trips into one, filters data at the source, and avoids the security risks of a code interpreter.
- The bounded language of nine permitted stages improves safety and accuracy, but limitations include regex not being semantic search and $limit silently truncating results, requiring prompt-level compensations.

## FAQ

### How does the agent avoid the security risks of a code interpreter?

The agent writes a MongoDB aggregation pipeline instead of arbitrary code. A handler validates the pipeline, prepends a tenancy filter, and executes it server-side. The permitted stages are allow-listed, and stages like $out and $merge are rejected, making the tool read-only by construction.

### What are the limitations of using aggregation pipelines for document review?

Regex is not semantic search, so retrieval quality depends on the agent thinking of the right synonym. Also, $limit can silently truncate results, making a subset look like a complete answer. The prompt compensates with synonym sweeps and coverage checks, but the floor remains.

### How does the agent handle cross-document relationships?

The agent writes a single pipeline that touches every file in the folder, pulls out only relevant sections, and returns them side by side with their source document. Cross-document comparisons happen in the database using stages like $unwind and $group, not in the context window.

**Tags:** [Aggregation Pipeline](https://yomu.fyi/topic/aggregation-pipeline), [AI Agents](https://yomu.fyi/topic/ai-agents), [MongoDB](https://yomu.fyi/topic/mongodb)

- Source: [MongoDB](https://www.mongodb.com/company/blog/technical/code-mode-without-interpreter-agents-that-write-aggregation-pipelines)
- Source URL: https://www.mongodb.com/company/blog/technical/code-mode-without-interpreter-agents-that-write-aggregation-pipelines
- Ingested by Yomu: 2026-10-08T15:00:17.648Z

[Read original post](https://www.mongodb.com/company/blog/technical/code-mode-without-interpreter-agents-that-write-aggregation-pipelines)