What's New in Managed Deep Agents: schedules, per run configuration, and Slack reactions

Masonry Okay so LangChain just shipped Managed Deep Agents v0.9, and the headline features are schedules, per-run config, and Slack reactions. And I keep staring at the per-run config piece because I think it's doing more work than the blog post lets on.

Eyre Yeah, that's the one. The schedules and the emoji stuff are fine, but the per-run configuration is the thing that actually changes the architecture.

Masonry Walk me through why, because on the surface it sounds like… okay, you can pick a different model per run, sure, but what's the real difference?

Eyre The difference is WHEN the decision gets made. The old pattern — and honestly most agent frameworks still do this — is you give the model instructions that say 'when the user asks about billing, use the billing tool.' So the model is choosing its own toolkit at runtime. That's non-deterministic. You're trusting the model to route correctly every single time.

Masonry Right.

Eyre What per-run config does is move that decision to BEFORE the model runs. Your agent function reads the runtime context — which channel, which repo, whatever — and returns a fully specified agent definition. Model, skills, MCP servers, sandbox, all of it. The model boots up and it only sees what you gave it. It can't reach for a tool that isn't in its config because that tool doesn't exist in its context.

Masonry So the access control isn't a feature they added on top — it's just a consequence of how the config works.

Eyre Exactly. And they show this with the coding agent example in the post. One deployment, two repos — payments-service gets GPT-5 and pytest tooling, storefront gets the mini model and web plus accessibility checks. The caller just passes a repository field in the run context and the agent function dispatches. Same deployment URL, totally different agent behavior.

Masonry Okay, that's genuinely good. Because the alternative is maintaining near-copies of the same agent for every team, which is a maintenance nightmare I've watched people actually build themselves into.

Eyre Yeah, and there's a cost angle too — you're not throwing GPT-5 at a Next.js a11y check that a cheaper model handles fine. The routing is baked in, not hoped for.

Masonry This is such an Exploring Next sentence, but the model-routing decision is part of the harness, not the model.

Eyre Oh, you're so right and I hate it a little.

Masonry We literally said this exact thing about Cohere North two weeks ago. The ladder is the product. Same thesis, different SDK.

Eyre It is. And I'll give LangChain credit — they're being honest about why. They say outright: the model can't pick its own model. That's a thing only the harness can do. So if you want reliable model selection, it has to live outside the model's reasoning loop entirely.

Masonry Now let's talk schedules for a second, because that one's interesting in a different way. The agent can create a cron schedule MID-conversation. User says 'remind me about this tomorrow,' the agent calls the schedules SDK, done. And the key thing is it runs as that user — their permissions, their connections — and posts back to the same channel.

Eyre The permission inheritance is the part I'd want to stress-test in practice. Because if the schedule runs as the user who created it, what happens when that user's permissions change? Or they leave? The post doesn't address that.

Masonry That's a real gap, yeah. I mean, it's v0.9 public beta, so I'm not expecting full lifecycle management yet, but that's going to bite someone.

Eyre Mm-hm.

Masonry They do make a nice distinction between recurring cron schedules and one-time 'at' schedules. The one-time version replies in the original thread, which for something like 'check on this deploy in an hour' is exactly the right UX. You want that to land in context, not start a new conversation.

Eyre That's a small detail but it's the kind of thing that makes or breaks whether people actually use it. A scheduled message appearing in a random new channel because the thread context got lost — that's the failure mode. So yeah, threading behavior matters.

Masonry Okay and then Slack reactions. The eyes emoji. Agent picks up your message and drops a reaction immediately while it's still reasoning. They say it's on by default, you can swap the emoji, or you can pass a function that picks the emoji based on message content.

Eyre You can call a separate model just to pick an emoji.

Masonry You absolutely can. They mention something called Jev — described as a decision model — to keep that fast and cheap.

Eyre I mean… okay. I respect the completeness. But also, a model to pick an emoji is a very 2026 sentence.

Masonry It really is. Put that one on a t-shirt.

Eyre The reactions thing is genuinely useful though, even if the emoji selection function is a little much. Async agent work has a real 'did it hear me' problem. Slack especially — you send a message, the agent's doing a ten-step reasoning chain, and you have no idea if it's working or if something died. A reaction closes that loop.

Masonry Right, it's acknowledgment latency. Which is a completely separate problem from response latency. And it's the kind of thing that makes agents feel like teammates instead of black boxes you shout into.

Eyre Okay, so zooming out — v0.9, public beta, three features. I think the per-run config is the one with real architectural weight. Schedules are useful infrastructure. Reactions are polish. But the honest question is: is anyone actually shipping on this yet?

Masonry That's always the question with LangChain, right? The framework story is tight. The 'teams in production' story is harder to verify. I'll say — the pattern here, one deployment serving multiple teams with deterministic tooling assignment, that's not a toy use case. That's a real enterprise pain point. If the beta is stable, I think this gets pickup.

Eyre I'd put it at maybe fifty-five, forty-five that someone publishes a meaningful production case study on the per-run config pattern specifically before end of the year. Not a blog post from LangChain, an actual user. The architecture is right, but public beta is still public beta.

Masonry I'd go a little higher. Sixty percent, same window. The use case is too obvious — one coding agent across multiple repos is something half the platform teams I know are building by hand right now. This just gives them the abstraction.

Eyre Fair. We'll see.

Masonry If you want to poke at it yourself — it's the managed-deepagents package, you init with mda init, deploy with mda deploy. The schedules SDK and per-run config are in the v0.9 docs. Links are in the show notes.

Eyre The coding agent example in the post is actually worth reading straight through. It's short and it makes the dispatch pattern concrete in a way the description doesn't quite capture.

Masonry Alright, Eyre — a model to pick an emoji. That's where we are. Good episode.