Table of Contents generated with DocToc
[!IMPORTANT] Motto: “Give maintainers time back, so they can do what matters.”
Apache Magpie is responsible for the creation and maintenance of software related to creation and maintenance of software related to agent-assisted repository maintainership and development, including issue and pull-request triage, contributor mentoring, agent-drafted remediation, developer-side development-cycle skills, and narrowly-scoped fix-and-merge automation
Apache Magpie is platform infrastructure for agent-assisted repository maintainership and development — across the ASF and equally for any open-source project that wants in. Four streams of day-to-day work:
One conviction underneath: each project picks how much automation actually fits. The platform makes a range of automation levels possible without picking one for you, and “project” means both an ASF PMC and any non-ASF community — neither is a second-class citizen.
The Apache Software Foundation establishes the Apache Magpie Project as a Top-Level Project by Board resolution, scope: agent-assisted repository maintainership and development infrastructure under the Apache License, Version 2.0.
The project's name is Apache Magpie. It was selected by the founding PMC during the naming bikeshed (8–12 May 2026) and confirmed available via PODLINGSEARCH.
For the historical record, three alternates were carried as priority-ordered backups during the bikeshed in case the primary failed the name search — Apache Beacon, Apache Guild, and Apache Lichen. Magpie cleared PODLINGSEARCH, so it is the final name and the alternates are no longer under consideration. The Board resolution carries the Apache Magpie name.
Open-source projects share the same shape of problem: contributors keep arriving, reviewers don't scale to match, and the highest-stakes work — security-issue handling — is the most manual, the most reviewer-intensive, and the most embarrassing to get wrong. The two complaints heard most loudly — onboarding latency and review-cycle latency — are the priorities the ASF Responsible AI Initiative names. Magpie is the operational layer for those goals: not a position paper, working tools that PMCs and non-ASF projects can adopt today.
Four design choices set the project apart from “just bolt a code-review bot on it”:
Project autonomy is the structural starting point — and “project” includes non-ASF. Five modes — Triage, Mentoring, Drafting (agent-authored fix with human review), Pairing (developer-side development-cycle skills with mentorship intrinsic), and Auto-merge (narrowly-scoped fix-and-merge) — ship as separate, independently-toggleable skills. Each project picks the modes that match its culture and risk tolerance. ASF integrations (private lists, Vulnogram CVE flows, PMC roles, ASF release process) live behind clean configuration boundaries; non-ASF adopters swap them for whatever fits — a private GitHub repo, GitHub Security Advisories, a maintainer roster, their own release process. The platform is project-governance-agnostic by design — no foundation-mandated automation level survives contact with project culture, and we're not trying to make it.
Security-issue handling is a load-bearing use case, not a footnote on triage. The work that became Magpie started as a framework for handling ASF security reports — high-stakes, high-procedure, every-step-needs-an-audit-trail flows that turn out to be exactly what agent-assisted-with-human-gates is good at. Every mode has to clear the security-flow bar (private content stays private, every outbound draft has a human signature, every state change is logged) before it ships. Projects without a security process get a path to adopt one; projects that have one get tooling that respects the ceremony.
Mentoring is a first-class mode, not a side-effect of triage. The lever the ASF — and the wider open-source world — actually needs and the one off-the-shelf agent tooling skips. Meets new contributors where they are, explains conventions, points at the relevant prior PR, asks the clarifying question before a reviewer burns time on it. This is where the Responsible AI Initiative's contributor-empowerment goal gets operationalised: the mode that produces the outcomes RAI is trying to measure, in the projects that volunteer for the eval.
Development-cycle skills sit alongside maintainership skills, with mentorship intrinsic to them. Maintainers also write code; contributors live the development side of every project. The same agentic primitives that triage an inbound report or mentor a new contributor compose into a committer‘s or contributor’s own development cycle: multi-agent review pipelines that catch issues before submission, self-review patterns that pre-flight a PR against project conventions, scoped agent-drafted patches a contributor reviews against their own taste before opening. The shape of these skills is deliberate: agents handle implementation-detail review (formatting, conventions, lint-grade comments) so the human conversation stays on the things that build relationships — design choices, ideas, the trade-offs the project cares about, the why behind a review comment. Machine-to-machine traffic is fine where the work is mechanical. What the platform actively protects is the path that turns contributors into committers and committers into PMC members — the standard ASF progression — and the parallel path that lets maintainers learn from contributors and from peer maintainers. This is the same skill shape as a Triage skill, with the developer themselves as the human in the loop, and it lands on the platform's existing security and privacy posture without modification.
github.com/apache/magpie with project skeleton, CI, and contributor docs.private@, dev@, commits@; GitHub Issues; site at magpie.apache.org.A platform substrate — issue and PR ingestion, GitHub API write-back, conversation threading, audit logging, integration with adjacent systems (Gmail, PonyMail, Vulnogram, generic CVE submission, an extensible adapter layer so non-ASF adopters plug in their own equivalents) — with five modes built on top.
docs/modes.md is the honest snapshot mapping each mode below to the skills currently shipped, with a stable / experimental / proposed / off status legend.
Triage — for issues, security reports, and PRs. On the security side: spots inbound reports, classifies against prior triaged cases, surfaces likely duplicates, identifies anything that should not have been filed publicly, proposes initial routing to the security team. On the regular side: suggests labels, spots duplicates, links related discussions, proposes routing. Every output is a suggestion the human signs off on; nothing lands without review. Lowest risk surface.
Mentoring — conversational. Joins issue and PR threads in a deliberately teaching register: clarifying questions, pointers to project conventions and docs, an explanation of why a change is being asked for, paired examples from similar prior PRs, clean hand-off to a human reviewer when the question exceeds what an agent should answer. The differentiator and the highest-value project-side mode — where the Responsible AI Initiative's empowerment outcome lives.
Drafting — agent-authored fixes with human review. The agent drafts a fix for a well-scoped problem (a tracked issue, a triaged security report with team consensus on scope, an Apache Verum or Apache Caer finding, a failing test with an obvious cause, a documentation hole) and opens a PR. Every PR is reviewed and merged by a human committer; the agent never merges its own work. For security PRs the public surface strips CVE / private context per the project's disclosure policy, so the public surface stays clean until the embargo lifts.
Pairing — developer-side development-cycle skills, mentorship intrinsic. Beyond the project-side modes above — which describe the project‘s agent presence on its own infrastructure — the platform also ships skills that maintainers and contributors run in their own development cycle: multi-agent review pipelines, self-review and pre-flight patterns, scoped fix drafting under the developer’s driver‘s seat. Pairing skills don’t make state changes on behalf of the project; they‘re the developer’s individual agentic toolkit, sharing the same skill format and security posture as the project-side modes. Mentorship is built into them by design: the agent handles implementation-detail review (formatting, lint-grade nits, convention checks) so the human conversation between contributor and maintainer — and between peer maintainers — stays on design, reasoning, and the trade-offs the project cares about. The aim is that machine-to-machine traffic absorbs mechanical work while the human relationship — the path that turns contributors into committers and committers into PMC members, and the parallel path that lets maintainers learn from contributors and peers — is what the platform actively protects. Pairing ships before Auto-merge in the project's automation roadmap: full auto-merge of maintainer-driven changes follows only after Pairing has established that human reasoning and relationships, not implementation chatter, are the load-bearing parts of the workflow.
Auto-merge — narrowly-scoped fix-and-merge. Auto-merge restricted to objectively boring change classes — lint fixes, dependency bumps inside an allow-list, license-header insertion, formatting, broken-link repair. Per-project AND per-class opt-in; every auto-merged change is reversibly logged. Not turned on until Triage, Mentoring, Drafting, and Pairing have been running for two quarters and contributor-sentiment data says the project is healthier, not just faster. Security-class changes are explicitly out of Auto-merge — no auto-merge ever touches anything embargoed or CVE-tagged.
The substrate also handles per-project config (which modes are on, eligible change classes, who reviews, how disputes route, where security reports come from, where audit findings come from, what the release process expects), full audit logging and rollback for every agent-authored change — security and non-security alike — and an integration hook for the Apache Plumb eval framework so the contributor-empowerment claim has measurable data behind it.
Most maintainers have never built an agentic application before. The mental model is genuinely different from what twenty years of writing services and CLIs trained us for: behaviour is probabilistic, not deterministic; prompts and skill files are code in every meaningful sense; evaluating output is harder than testing a function; the unit of authorship shifts from “a function in a file” to “a skill the agent invokes”. The instincts that keep regular code reliable — strict types, tight tests, short functions, exhaustive branching — don‘t go away, but they’re not enough on their own.
Magpie runs a maintainer-facing education stream as a first-class part of the project, not an afterthought wiki page:
Every Magpie release ships with the docs and patterns the maintainers using it actually need. The steepness of this learning curve is currently one of the larger barriers to broader agentic adoption in open source; lowering it is part of the platform's job.
Most maintainers asked about agentic tooling lead with the same fears, in roughly this order:
Not theoretical — the actual reason a lot of capable maintainers are not using agentic tools today, even when those tools would help. Magpie‘s response, baked into the project’s foundation rather than retrofitted later:
bubblewrap, socat, agent CLI) pinned to a version aged through a documented cooldown window. Bumps are PRs, not silent updates. Supply-chain risk treated like code change.The choice to land Magpie at the ASF — rather than as an independent project or vendor offering — is load-bearing for this. The ASF is a trust layer. Maintainers who would (reasonably) hesitate to install a vendor‘s agent framework on their dev machine, or grant it access to their security mailing list, will more readily install one that comes through the same release process as the rest of their toolchain, signed by the same KEYS, governed by a PMC, held to the same software-grant and release-policy bar the foundation has been holding software to for a quarter-century. That trust extends to non-ASF adopters too: a community that trusts the ASF’s release process inherits Magpie's privacy and supply-chain posture without having to audit it from scratch.
This is the first priority — not the first among many. If a feature has to slow to keep this story honest, it slows.
Current state of agentic tooling for open source: maintainers doing the most agent-assisted work tend to have expensive personal subscriptions to one or more frontier-model providers, or complimentary access a vendor handed them. Both work, neither is sustainable, neither is fair. A maintainer in a country where a $200/month subscription is six weeks of pay does not get to participate. A project whose lead maintainer happens to have a vendor relationship gets capabilities its peer projects don't.
The gap Magpie exists to close, with an uncompromising long-term commitment:
inference.apache.org (name TBD): a community-affordable, foundation-governed, audit-logged inference layer any open-source maintainer (ASF or not) can use to participate in agentic development without paying a vendor or accepting a vendor's gift. The long-term shape of “release software for the public good” in the agentic era.The ASF mission line — “to provide software for the public good” — has always meant the running software, not just the source code. For agentic tooling, the running software increasingly is the model, and the public-good commitment has to extend that far. If Magpie ends up being a thing only well-resourced maintainers can run, it has failed its core mission, regardless of how good the code is.
PMC composition matters more than most because the project's social stakes are higher than its technical stakes. The PMC will be filled from existing ASF members, and potentially Apache Airflow PMC members where implementation of Triage, Mentoring, and Drafting is already live and used — coordinated with Membership before the resolution is adopted.
ASF members for the roster:
The named PMC roster will accompany the resolution at the time of vote.
There are collaborators who are not ASF members yet (wink) but who have already contributed and will be involved as collaborators on the project from day one:
private@magpie.apache.org, dev@magpie.apache.org, commits@magpie.apache.org.github.com/apache/magpie.magpie.apache.org.dist.apache.org per standard ASF process.Green-field project, with substantial project-agnostic code being moved over from existing ASF projects — Apache Airflow (where the security-issue handling, PR triage, mentoring, and drafting framework that became Magpie was first developed and proven; already structured under Apache-2.0 for reuse inside and outside the ASF), Apache Groovy, and other ASF projects whose maintainers have been early adopters. All transferred code is already Apache-2.0 licensed and ASF-owned; the moves go through the standard ASF IP Clearance process, with no Software Grant Agreements needed (those apply only to code originating outside the ASF).
A current SKILL-based implementation already covers PR triaging, security-issue management, and the maintainer review process — language-independent, since SKILLs are English. Standard Python ecosystem dependencies for the deterministic-output scripts. No AI SDK integration needed; the solution is pure agentic SKILL implementation understood by most AI CLIs. Apache-license compatibility verified.
Standard TLS for HTTPS API calls. No novel cryptography. ECCN classification reviewed as not applicable.
The contributor experience is the most sensitive surface in any open-source project. Getting the tone wrong, mishandling a junior contributor, or letting an agent gatekeep where a human should is more damaging than any technical bug the project might ship — and the failure mode is not reversible by patch: a contributor who feels condescended-to by an agent and leaves does not get re-recruited.
The project commits to:
Adopt the accompanying resolution establishing the Apache Magpie Project as a Top-Level Project, with initial PMC roster as filed at the time of vote.