MCP Servers Behaving Badly
Plus... sandboxed agents, feature drift, secure RAG, coding subagents, and Databricks’ Omnigent.
Plus... sandboxed agents, feature drift, secure RAG, coding subagents, and Databricks’ Omnigent.
Positive news from OpenAI on open-source security, though the name sounded familiar...
HOT TAKE
RAGrets
Your RAG eval can be green while the wrong user sees the right chunk.
When retrieval gets sensitive, what matters more - relevance or authorization?
LAST WEEK’S TAKE
On the Trail
Evals are trailing, with 80% putting more trust in audit logs when agents fail.
HIDDEN GEMS
Curated finds to help you stay ahead
Cursor’s strict code review checklist targets maintainability, structural simplification, oversized files, messy branching, weak abstractions, and type-boundary problems that can block approval.
For running agents and risky CLI commands, Fence applies filesystem rules, default-deny network access, command blocks, and reviewable policies on macOS and Linux without requiring a VM or container.
TypeScript Harness for Autonomous Agents
For building autonomous agents, Flue provides a TypeScript harness with sessions, tools, skills, filesystem access, sandboxed execution, workflows, telemetry, and local or hosted deployment options.
Cloudflare’s Agent Engineering Stack
Inside Cloudflare’s internal rollout, engineers connected AI Gateway, Workers AI, MCP portals, AGENTS.md, Backstage, and AI code review to support secure coding-agent use at scale.
OPEN SOURCE SOFTWARE
Omnigent, a control layer for messy agent workflows multiple agents
Agent work is starting to look a lot like browser-tab chaos for terminals. Claude Code in one terminal, Codex in another, maybe Pi or a custom agent for a specific job, a sandbox or two, a pile of credentials, and an approval step that lives in someone’s head. Work gets copy-pasted between agents, Docs, and Slack. Each harness only understands its own sessions, so nothing carries over when you switch tools.
Earlier this month, Databricks open sourced Omnigent under Apache-2.0. It calls itself a meta-harness: a common interface that wraps Claude Code, Codex, Pi, and agents you write yourself, then adds the things a single harness rarely gives you across tools, like collaboration, policies, cost caps, and cloud execution.
What it is
The core idea is that, however each harness talks to its model internally, the interface to the user is the same: messages and files in, text streams and tool calls out.
Omnigent builds one API over that and splits the system in two. A runner wraps an agent in a sandboxed session and executes the loop and tools, either on your machine or in a cloud sandbox. A server handles persistence, policies, sharing, and access from terminal, browser, phone, or the macOS app.
The split keeps code execution and model credentials on the host side rather than in the server, which matters if you care where your secrets live. (cough cough enterprise-ready)
Omnigent wraps agent harnesses in a runner, with a server handling policies, history, MCPs, skills, and shared interfaces. Image: Databricks
Why it matters
Let’s look at what this lets you build once the agents are interchangeable:
Collaboration on the session, not the chat window. Share a live session by URL, watch it run, comment on files, co-drive it, or fork it. The session is the shared object, so a teammate or reviewer joins the work rather than a transcript of it.
Contextual policies. Rules that track session state instead of static allow/deny. The example from the docs is gating git push only after an agent has installed a new npm package. Policies stack across server, agent, and session, with the stricter rules checked first.
Cost caps. Per-session spend tracking with hard caps and soft warnings, so a sub-agent tree cannot quietly burn through tokens. You can tell it to pause and ask after every $100. (Or if you are like me, have it play a cha-ching sound and Fat Joe/Lil Wayne make it rain at full volume)
Cloud execution. This is becoming table stakes now. Nobody is excited about keeping their laptop open on the metro.
Multi-harness authoring. Probably the most interesting for me. Define an agent in one YAML file covering prompt, executor, tools, policies, and sub-agents, then switch harnesses with a one-line change, or mix harnesses inside the same agent.
Meta harness & Loop engineering
Addy Osmani’s recent writing on loop engineering argues that the work has shifted from prompting one agent to designing repeatable systems of worktrees, sub-agents, connectors, and persistent state.
Omnigent reads as a control layer for that shift. The bundled Polly example is a lead agent that plans, hands coding to sub-agents in parallel git worktrees, and routes each diff to a reviewer from a different vendor than the one that wrote it. Debby runs the same question through a Claude head and a GPT head side by side and lets them debate.
So the fit is workflows like planner plus coder plus reviewer, cross-vendor adjudication, and a team working a single repo state together. The current docs lean harder on orchestration, collaboration, and policies than on scheduling and automation, so today Omnigent is less a finished loop product and more a substrate you build loop-style workflows on.
What looks promising
A real abstraction if you already run more than one harness or model family, rather than a wrapper around one.
A more explicit governance story than a lot of open-source agent tooling: contextual policies, spend caps, and approval gates built in.
Collaboration primitives that are part of the session model, not bolted on afterward.
A YAML agent spec that makes multi-agent, multi-harness setups legible for a platform team.
What needs caution
This is alpha. The repo is clearly early, carries an explicit alpha badge, and there is not much independent operator feedback yet, so almost all the public evidence is launch material. Treat any judgment on ergonomics or reliability as provisional until people have run it on real repos.
The setup surface is also wider than the one-line install suggests. You need Python 3.12+, uv, git, and Node.js 22+ for the Claude/Codex/Pi harnesses, plus tmux for the native wrappers. Remote deploys add database choices, memory floors, slower first boot against remote Postgres, and provider caveats like Modal’s 24-hour sandbox lifetime and Daytona’s free-tier egress limits.
The biggest operational risk is that the collaboration features cut both ways. Co-drive means another user’s messages can execute on your machine, and the docs warn that header-based auth is dangerous unless a trusted reverse proxy rewrites identity headers correctly. Get that wrong and one caller could impersonate another and reach sessions, files, and history. Cross-vendor loops can also raise token spend fast, and if your team is standardizing on one harness anyway, Omnigent may be more control plane than you need.
In practice
I got early impressions from my friend Mateo (who is a much better engineer than myself).
Setup was genuinely easy, which is worth noting against the dependency list above. His take was that Omnigent simplifies the loopcraft idea a lot, and that for someone already running their own custom multi-agent setups the tradeoff is versatility against ease.
Bespoke stacks still offer more flexibility, and can go further than Omnigent’s static YAML-led setup. Gas Town and the newer Gas City SDK, for instance, can run a coordinator agent that watches a task tracker and hands work out to other agents on its own. But, the Gas projects are also far harder to stand up, and Omnigent closes most of that gap with much less effort.
The main limitation was around MCP. Today, an MCP server is wired in either as a local command or a remote URL with a bearer token, which means keeping tokens on your machine or in the Databricks config. He would prefer MCP OAuth with dynamic client registration so credentials are not sitting locally. I’m sure this will change soon. (Friend of the pod Corey Zumar is doing a ton of work on Omniagent, and that guy ships)
Between CLIs, MCP, and Agent Skills, switching between harnesses is already possible without much ceremony, and a team running one or two agents may find their own light glue does the job.
I know in our Friday coding agent sessions folks have asked how others are using coding agents in teams now. The case for Omnigent gets stronger as the coordination problem grows: several harnesses, multiple people, work moving across machines, and policies or spend limits that need to hold across all of it.
JOB OF THE WEEK
Senior AI Software Engineer, Internal Enablement // Extend // Remote US
Extend is hiring a senior engineer to build internal AI tooling for non-engineering teams. The role focuses on secure MCP connectors, reusable agent skills, credential management, observability, and infrastructure for turning prototypes into reliable internal tools.
Responsibilities:
Design secure MCP connectors across finance, CRM, data, support systems.
Build shared agent skills and review patterns for internal teams.
Build connector agents that scaffold MCP servers and provision access.
Instrument MCP calls, skill execution, and credential use with OpenTelemetry.
Requirements:
Five-plus years shipping production systems and improving failure points.
Strong Python, TypeScript/Node, or Rust production engineering experience.
Experience building OAuth integrations, webhooks, retries, and rate limits.
Familiarity with AWS, IAM, KMS, Lambda, and serverless risks.
MLOPS COMMUNITY
The Dark Side of MCP Servers
A broken MCP server can make a capable agent look useless, and a malicious one can change the tools it exposes after you already trusted it. This podcast looks at what has to improve before MCP feels safe in production.
Toolbench and MCP Debugger expose protocol failures, misstated capabilities, broken auth, and bad tool schemas.
Skills, CLIs, and MCP solve different problems once agents move beyond local coding workflows.
OAuth-based MCP keeps user identity outside the prompt, reducing spoofing and token misuse.
Reliable agents need boring protocol behavior before they get dangerous work.
Sandboxing, Agent Harnesses, and Agent Teamwork
An SRE agent that gets 70% right can still send an engineer down the wrong path during an incident. This podcast looks at why production agents need more than better models.
Harness design has to evolve as models improve, relaxing rigid tools while adding stronger sandboxing.
Verification matters more than the agent loop, especially across messy production environments.
Slack history, code, logs, and human feedback can teach agents local rules and decision bounds.
Better agents need clear boundaries, fast feedback, and humans reviewing the decisions that matter.
Roundtable: Building Real-Time ML Systems with Zipline + Chronon
A feature can look right offline and still be wrong when it hits serving. This round table looks at why teams are moving feature pipelines toward Chronon and Zipline as models, ranking systems, and real-time use cases grow.
Batch and streaming definitions can share one authoring path, reducing training-serving drift.
Point-in-time joins, backfills, and online lookup become platform concerns instead of product-team chores.
Adoption still carries cost, especially around debugging, versioning, and fitting existing data assumptions.
For growing ML systems, feature correctness is where speed either holds or breaks.
Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use
A RAG system can retrieve the perfect chunk and still show it to the wrong person. This discussion looks at the security gap behind multi-tenant agent systems, where relevance scores alone are not enough.
Authorization has to happen at chunk level, before retrieved context reaches the model.
Predicate pushdown helps preserve recall by filtering tenant access inside the vector database.
Server-side orchestration gives teams a stronger place to enforce policy on tool calls and retrieval.
The danger starts when retrieval works, but access control arrives too late.
Supagents: One Source to Rule Your Coding Subagents
One Friday tweak to an agent persona can quietly turn into five different behaviors across five coding tools. This blog shows how supagents keeps Claude Code, Gemini CLI, Copilot, Cursor, OpenCode, and Kilo Code aligned from one markdown source.
Shared instructions live in
.agents/supagents/, then compile into each tool’s expected agent format.Per-tool frontmatter stays verbatim, so fast-changing agent config does not need a fragile translation layer.
Pre-commit and CI checks stop generated agent files drifting from the source.
A small compiler can save a lot of debugging when every agent starts from the same instructions.
VIRTUAL EVENTS
The Current State of Agentic Retrieval - June 25
Coding Agents Lunch & Learn Session - June 26
MEME OF THE WEEK
ML CONFESSIONS
Feature Drift Store
We added a feature store so the training pipeline and the serving path would read the same features. The whole point was to stop the two drifting apart.
A churn model had been live for about five months with no obvious issues. Then retention asked why a batch of flagged accounts had canceled weeks earlier. We spent two days assuming it was a labeling problem on their end.
It wasn’t. The serving path was reading the feature store. The training pipeline was still reading the old offline tables nobody had pointed at the store. Same feature names, same schema, values computed a day apart. Close enough that nothing looked broken and far enough off to matter.
I didn’t have a clean fix. I backfilled the store from the offline tables so at least they matched, and left the proper migration as a ticket. It’s still open.
Share your confession here.