RFC: which agent runtime pr-agent adopts after v1 (tools, MCP, budgets)

[IsmaelMartinez]

pr-agent makes one model call per prompt and cannot call a tool. That blocks MCP, tool use and reading outside the diff, and it is why good PRs in that area keep getting closed. This RFC is to agree on the runtime first. I am working on the architecture and the order of work, and will put that proposal up once we have agreed on the tool.

Please do not implement anything before we have reached agreement, and this is work for after v1; we are at 0.45.0 with no date for either. Until then the focus is bug fixes and implementation aligned with what exists. I will be opening bug tickets and feature tickets that I would appreciate contributors focusing on.

Three terms, so the rest reads on its own: a round is one model call plus the tool calls it asks for; host-only means set by whoever runs pr-agent, never by a repository's .pr_agent.toml; static injection is what skills and repo_context do today, context fetched up front at zero extra calls.

The comparison is on one page, Agentic Substrate Options. The short version:

• Four gates cut twenty-odd candidates to three: an OSS licence with nothing behind a paid product; no telemetry to the vendor by default, because the input is a private diff; runs on top of litellm's provider matrix rather than beside it; and a hard bound on the loop, because a loop re-sends its growing context every round (with five 8 kB tool results a round an event costs twice today's $0.13 by round four) and the budget must be host-only.
• Proposal: PydanticAI (MIT) through a custom Model over the existing litellm handler, so the provider matrix stays in one place and the surface we depend on is one method and two properties. Its request, tool-call and token limits are checked before each call, its OpenTelemetry sends nothing to a vendor, and it fans out and resumes from a persisted message history on its own. LangGraph (MIT) is the alternative only if its checkpointer is worth sixteen packages. A litellm-native loop was weighed as an interim and dropped: the harder half is thrown away when a framework lands, together with every option people had set for it.
• MCP comes as a tool source over HTTP once the design allows it; a static call with templated arguments needs no loop at all, and stdio MCP never runs inside the webhook servers.

What I want answers to:

1. Budget in dollars, or in calls and tokens? Dollar limits stop enforcing on Ollama and custom endpoints: the loop keeps running.
2. Any objection to PydanticAI's release cadence (about 200 releases a year, hard removals in 2.0) as a dependency, given the adapter we would own is one class?
3. Is anyone running PydanticAI or LangGraph against non-OpenAI providers in production?

@naorpeled, @DanaFineTLV, @ofir-frd: I would value your view on these three.

This supersedes Discussion #2646 (thanks @salakhovilia for the first MCP ask on this tracker) and my own #2944, which took over from @universam1's stalled #2348. I am closing #3093, #3095 and #3099 and PRs #3094, #3096 and #3100 from @dwin-gharibi in favour of this thread; their round and result caps, host-only endpoints and allowlisted plugins are recorded for the architecture proposal that follows.

[dwin-gharibi]

This feels like an important step for PR-Agent and ultimately, for taking it into its next generation! 🚀

Having a proper agent runtime with tool use, MCP support, controlled budgets, and the ability to reason beyond the diff could unlock a lot of what PR-Agent has the potential to become. I really like the focus on agreeing on the architecture first rather than rushing into implementation. 🧩

We’re excited about this direction and would be happy to contribute to the development once the architecture is agreed upon. 🙌 Whenever the design is settled, we’d be glad to pick up and work on parts of the implementation where we can help.

Looking forward to seeing PR-Agent evolve into its next generation! 🚀✨