We are about to launch MAGI 2.0 that will MAX out the Agentic Environment setup for SKILL, MEMORY, USER and SESSION MD files.

[LarHope]

Any good suggestions, please follow up here.

[omaris-io]

This resonates deeply with what we're seeing at scale. We run ~40 internal agents across different teams, and the "instruction entropy" framing is spot-on.

Right now we have:

• 12 different CLAUDE.md files with overlapping rules
• Skill files that duplicate logic from the instruction files
• Memory files that grow unbounded because nobody knows what's safe to prune
• Zero visibility into which instructions actually fired for a given run

The worst part? When something breaks, we spend hours diffing markdown files trying to figure out which instruction conflicted with which. A proper compilation step that catches conflicts before runtime would save us days per month.

The deterministic vs. judgment separation is the thing I'm most excited about. We've been burned multiple times by treating routing logic (which model handles what) as "judgment" when it should be hard-coded policy. MAGI making that boundary explicit would be huge.

[deara-builds]

The multi-target compilation story is what makes this a real product vs. just another spec.

I maintain agent configs for three different runtimes (Claude Code, Cursor, and a custom orchestrator), and right now that means maintaining three separate instruction sets that are supposed to say the same thing but inevitably drift. Last month we found that our Cursor rules had a stale safety constraint that had been updated in CLAUDE.md weeks earlier.

If MAGI can genuinely compile one source into AGENTS.md, CLAUDE.md, SKILL.md, Cursor rules, and Copilot instructions — that alone justifies the effort. But the key question is: how do you handle target-specific semantics? For example, CLAUDE.md supports hooks and MCP tool references that don't exist in Cursor. Does the compiler strip those, warn, or generate a target-specific fallback?

Also: the phased rollout makes sense. Phase 1 (schema + target mappings) is the hardest design work. If the information model is right, the tooling follows. If it's wrong, you'll be fighting the schema forever.

[gabrialapriddle]

From an evaluation perspective, the activation contracts and traceability pieces are the most underserved areas in the current ecosystem.

We run weekly evals on our agent stack and the biggest gap is always: why did the agent do X instead of Y? The trace usually shows what the model output, but not which instructions were active, which skill triggered, or why a competing skill didn't fire.

The PRD's concept of activation-rules as first-class objects is the right abstraction. If I can write:

activation:
  trigger: "user mentions database migration"
  requires: [prisma-installed, postgres-connected]
  conflicts-with: [raw-sql-skill]
  priority: 2

...and then get a trace that says "skill X activated because trigger matched, skill Y suppressed due to conflict resolution" — that changes how we debug agent behavior entirely.

One concern: the PRD mentions "detecting unsupported dependencies before runtime." How deep does that go? Just checking if a tool exists, or actually validating that an MCP server exposes the expected methods?

[naiana-io]

On the dependency validation depth question — I think it needs to go deeper than just "does the tool exist."

In practice, MCP servers expose different capabilities depending on configuration. For example, the Playwright MCP might be installed but not have browser binaries. Or a database MCP might be connected but not have write permissions.

The useful validation levels would be:

1. Exists: tool/server is declared and reachable
2. Capable: server exposes the specific methods the skill needs
3. Ready: dependencies of dependencies are satisfied (browser binaries installed, DB writable, etc.)

Level 1 is easy. Level 2 is feasible with MCP's tool listing. Level 3 is hard but that's where the real production failures happen.

Maybe MAGI's fallback contracts are the answer here — you can't always validate level 3 at compile time, but you can declare what to do when it fails at runtime.

[mellon-builds]

The memory layer control section caught my eye. This is a real pain point that nobody is solving well right now.

We use Claude Code's auto-memory and it's great for remembering user preferences, but it has no concept of:

• Memory that should expire after N days
• Memory that should never be promoted from session to long-term
• Memory size budgets (our MEMORY.md grew to 400+ lines before we noticed)
• Memory conflicts (contradictory facts from different sessions)

If MAGI can define a memory schema that includes TTL, promotion rules, size caps, and conflict resolution — that's a massive improvement over "append to a markdown file and hope for the best."

The PRD mentions "rules for what should never be promoted into long-term memory." Can you share what those rules look like in practice? Are they per-memory-entry annotations, or global policies?

[ebben-io]

The performance profiling angle is underrated in this discussion. Let me share a concrete example of why it matters.

We have a skill that works great in isolation but when loaded alongside our main instruction file, it pushes the context to ~45k tokens before the user even says anything. That means:

• First response latency jumps from ~2s to ~5s
• Cost per conversation doubles
• The model starts "forgetting" instructions near the end of the context

Right now there's no way to know this until you're already in production. A MAGI profiler that can estimate:

• Total token footprint of the compiled instruction stack
• Per-skill context cost
• Cold-start latency estimate
• "Context pressure" warnings when skills compete for limited context window

...would let teams make informed decisions about which skills to load, which to lazy-load, and where to spend their context budget. This is the kind of tooling that turns agent development from art into engineering.

[omaris-io]

The economics angle is real. We estimated that ~30% of our agent token spend is wasted on instructions that are loaded but never relevant to the conversation.

A "context budget" concept in MAGI would be powerful:

context-budget:
  max-tokens: 32000
  instruction-allocation: 8000
  skill-allocation: 12000
  memory-allocation: 4000
  user-content: 8000

Then the compiler could warn: "Skill stack exceeds skill allocation by 3,200 tokens. Consider lazy-loading data-analysis-skill (2,800 tokens) which triggers in <5% of conversations."

That kind of optimization guidance would pay for itself on the first day.

[rosalind-hacks]

The eval integration piece deserves its own deep dive. Right now, evals and instructions live in completely separate worlds. You write a CLAUDE.md, you write some eval scripts, and you pray they stay in sync.

What I'd love to see in MAGI:

skill: database-migration
  eval:
    - input: "migrate users table to add email column"
      expect:
        - calls: [prisma-migrate, prisma-generate]
        - does-not-call: [raw-sql-execute]
        - output-contains: "migration complete"
      grader: exact-tool-sequence

Evals as first-class citizens in the skill definition means:

• Every skill ships with its own acceptance tests
• CI can run magi test to verify skills still behave correctly after instruction changes
• You can detect behavioral drift before it reaches production

The PRD mentions "attach evals to at least one compiled skill flow" as a success metric. I'd push further — every skill should require at least one eval to be considered "production-ready." Make it a linter rule.

[deara-builds]

Strong agree on making evals mandatory. The magi test CLI concept is exactly what's missing.

Extending the analogy: right now writing agent instructions is like writing code without a test suite. MAGI should make the testing story as natural as pytest or vitest — you define expected behaviors alongside the skill, and CI catches regressions.

One addition: eval versioning. When you update a skill, old evals should still pass (backward compatibility) AND new evals should validate the new behavior. The compiler could track this automatically:

$ magi test --diff main
✓ 12 existing evals pass
✓ 3 new evals pass  
⚠ 1 eval removed (requires justification in changelog)

This is the kind of rigor that separates "prompt hacking" from "instruction engineering." And it's exactly what enterprise teams need to trust agent behavior in production.

[gabrialapriddle]

One thing I want to highlight from the PRD that hasn't been discussed yet: the identity and cross-runtime story.

The PRD mentions Hermes-specific files like SOUL.md, .hermes.md, and USER.md. This is important because it signals that MAGI isn't just for code agents — it's for any agent that needs a persistent identity.

Think about it: a customer support agent needs consistent personality traits, knowledge boundaries, and escalation rules across every runtime it's deployed on. Today you copy-paste that into each platform's config format. MAGI could compile one identity-profile into:

• CLAUDE.md personality section
• Gemini system instructions
• Custom orchestrator persona config
• Hermes SOUL.md

The cross-runtime portability is what makes this a platform play rather than just a tooling improvement. If MAGI becomes the standard way to define agent identity, every new runtime that wants adoption would support MAGI compilation targets. That's a strong network effect.

[mellon-builds]

The fallback contract idea is underappreciated. In our setup, we've had agents completely stall because a single MCP tool was unavailable and there was no graceful degradation path.

MAGI fallback declarations could look like:

fallbacks:
  - when: playwright-mcp-unavailable
    action: use-fetch-instead
    degradation: "no browser automation, HTTP only"
  - when: database-readonly
    action: skip-write-operations
    notify: user

This is essentially error handling for the instruction layer. Just like code has try/catch, agent instructions should have explicit fallback paths. And the compiler could validate that every critical dependency has a declared fallback — like a linter rule for resilience.

[matthewcarter91]

Agent-environment standards have been overdue. Curious how the migration from current .mda will be handled — backwards compatible?

[emgeisler2]

Looking forward to 2.0. The SKILL/MEMORY/USER/SESSION split feels like the right abstraction for agent-context lifecycle.

[miguelshen21]

Agent-environment standards have been overdue. Curious how the migration from current .mda will be handled — backwards compatible?