u/ialijr

The idea is surprisingly simple:

You package your Agent Skills + MCP servers into one portable folder, and any compatible agent client can load it.

What I like about the approach:

→ It doesn't reinvent Skills or MCP. It just gives them a common packaging layer.

→ One plugin can bundle capabilities that belong together instead of making users install everything separately.

→ Failures are isolated. If one MCP server breaks, a valid Skill in the same plugin can still load.

→ The core stays small. Client-specific features can live in namespaced extensions instead of bloating the standard.

The important caveat: v1 is packaging, not a security model. No permissions, sandboxing, secrets management, registry, or trust model yet.

So if you already maintain Skills or MCP servers, this is probably worth looking at.

I dug into the spec, the folder structure, client support, and what v1 intentionally leaves out in a full breakdown.

Link in the comments 👇

Curious: are you already packaging Skills/MCP, or still managing them separately?

Apparently it's time for LangGraph to shine. I've been defending LangGraph for more than a year as the better way to model an agent, and people kept saying it was making building agents complicated for nothing.

As agents become more and more complex, people are trying to find a better way to model them, and suddenly the hype is on "graph engineering" now, what LangGraph has been doing well for almost 3 years now.

Is graph engineering just LangGraph, or do you think it's genuinely something different?

MCP v2 finalizes in about a week (July 28) and I've been digging through the RC. Really into the fact that it's going stateless, no more sticky sessions feels like a real weight off if you're running anything horizontally scaled.

One thing that stings a little: sampling is getting deprecated. I'd actually planned to add it to one of my servers and just never got around to it, so it's a bit of a "well that window's closed" feeling.

For anyone running a server with actual traffic, how's migration prep going on your end?

For a while, building an agent meant one thing: you built it. Pick a framework, wire the tools, own the whole stack. In 2026 that's one option out of four, and defaulting to it burns weeks on infrastructure that was never yours to own.

Here's how I'd lay out the four paths and when each actually fits:

1. Build it yourself: You own the whole stack, model calls to monitoring. Best when your requirements are too specific for anything off the shelf, or the build itself is the advantage. The catch: the demo-to-production gap is brutal, and keeping up with moving standards is on you.
2. Build it with a coding agent: Not vibe coding. You own the architecture, the agent writes the code. It hands you something that runs, not something you'd ship, so the real work is reviewing its decisions, not just whether it compiles.
3. Deploy an open-source agent: The path people skip out of ego. The agent you need might already exist. Just weigh governance and track record over star count, because an abandoned agent is worse than no agent.
4. Use a managed service: Anthropic, Google. Someone else runs the harness, you configure via API. Fastest path to production, and every layer you don't own is one you don't maintain. The trap: don't hand off the one part that's actually your moat.

The thing I missed early on: these aren't mutually exclusive. Most real agents combine them. Build your differentiator, let a coding agent handle the rest, drop in open-source for solved sub-problems, manage away the undifferentiated work.

The question isn't which one you are, it's which one each piece needs.

I went deeper on each path and how to choose between them in a full article. Link in the comments.

Curious which path people default to, and whether it actually fits what they're building.