Repository navigation
Pydantic AI as an agentic engine #50971
Description
Activity
- locked and limited conversation to collaborators
on Aug 7, 2026 - unlocked this conversation
on Aug 7, 2026 @copilot allow allow behavior driver parsers to define log parsers.
Added log-parser in the latest build.
@copilot add a definition based pydantic.md shared agentic workflow and a smoke-pydantic.md smoke Aw to test the integration. Review the issue to find more information about the pydantic-ai-harness.
- linked a pull request that will close this issueAdd Pydantic AI shared engine definition and smoke test #51161
on Aug 7, 2026 Related work on the pydantic-ai side: pydantic/pydantic-ai#7276
- locked and limited conversation to collaborators
on Aug 7, 2026 - unlocked this conversation
on Aug 7, 2026 hey @pelikhan , thank you for giving this a shot
I tried out the engine but as expected it doesn't work (as mentioned above, there's some more work to be done on our side)
the biggest problem is that the agent that the engine creates has no shell or file system.
we'd like to keep working on this, thus would it be possible to reopen the issue and revert the current integration? or at least remove it from docs/announcements so people aren't compelled to using it? otherwise people will think that our stuff doesn't work.
if you'll allow us we'll create a PR ourselves after we've done the work on our side.
Reacted by Peli de Halleux4 remaining items
- locked and limited conversation to collaborators
on Aug 17, 2026 - unlocked this conversation
on Aug 17, 2026 Here is a pr - https://github.com/github/gh-aw/pull/53542/files
once you have it merged, I will update engines.json to point to the repo.
This is better as you keep ownership and the implementation.
- locked and limited conversation to collaborators
on Aug 25, 2026 - unlocked this conversation
on Aug 25, 2026 Yes correct... well we could host it here too and guess but you would have to send issue-as-spec to maintain it. Both work.
This comment was posted by Claude Code using claude-fable-5-1 on behalf of David.
Hi @pelikhan, the definition is merged and lives on
mainof pydantic/pydantic-ai-harness:pydantic/pydantic-ai-harness/gh-aw/pydantic.md@main. User docs: https://github.com/pydantic/pydantic-ai-harness/blob/main/gh-aw/README.md.Two things in the compiler to look at when you repoint
engines.json, from reading currentmain(4c43622):knownEngineImportWithCompilerRefinpkg/workflow/engine_definition.goappends the gh-aw CLI version as@<ref>to any catalog import that has none. That ref does not exist in our repository (our tags arev0.26.0and so on), so the tip in the compile error would name a 404. An import outsidegithub/gh-awneeds@main, or a ref carried by the catalog entry.TestKnownEngineImportsFile_MatchesSharedEngineFilesinpkg/workflow/engine_definition_test.goforbids@in catalog imports and requires every engine under.github/workflows/shared/to be listed there, so the shared copy ofpydantic.mdand the test move together with the repoint.
- locked and limited conversation to collaborators
on Sep 9, 2026 - unlocked this conversation
on Sep 9, 2026 @dsfaccini can file new issue? The long history bloats the context. Best to link new issue for new work.
Reacted by David SFThis comment was posted by Claude Code using claude-fable-5-1 on behalf of David.
Done: the repoint is #59755, written as a plan with the files, the compiler-ref change and the verification steps. Nothing further is needed on this thread from our side.
- locked and limited conversation to collaborators
on Sep 9, 2026 - unlocked this conversation
on Sep 9, 2026
hey guys! @strawgate brought agentic workflows to our attention a couple months ago and we've been
using them since then (https://github.com/pydantic/pydantic-ai/tree/main/.github/workflows, pydantic/pydantic-ai#7211, pydantic/pydantic-ai#7253 (review)).
in parallel we've been running our own handrolled agent that does triage and review in our repo pydantic/pydantic-ai#7235 (comment).
we like agentic workflows and want to keep using them, while also dogfooding our own stack, which
is why we want to build a Pydantic AI based engine pydantic/pydantic-ai-harness#569 following the third-party model in your https://github.github.io/gh-aw/reference/engines/
claude's helping me build it so I'll leave its description below, + some questions we have for you guys so we can make the right choices
thank you for your time and attention!
the shape. An owner-maintained engine definition (
engine: {id: pydantic-ai, behaviors: ...})published in pydantic-ai-harness and imported
pinned to a tag, backed by a headless coding-agent CLI installed via
runtimes: {uv: {}}+pre-agent-steps(theaider.mdpattern), withsecret-strategy: universal-llm-consumerforauth. Nothing needs to live in your repo or binary -- users import the definition from ours.
built already (pydantic-ai-harness#569):
the engine definition and a smoke workflow, compile-tested:
pydantic-aiengine id imported from a shared definition compiles clean with--strictonv0.85.4. we bisected the releases: v0.84.3 still rejects new ids, the Refactoring opencode integration for shared workflows #50145 fix lands in v0.84.4.
we'll document v0.85.4 as our minimum supported version.
owner/repo/path.md@tag) resolve, SHA-pin, and vendor correctly --tag, branch, and bare-SHA refs all work.
engine: pydantic-ai) errors even when thedefinition is imported -- only the object form (
engine: {id: pydantic-ai}) works, and the errormessage doesn't hint at that. cost us a minute; will cost every new user a minute.
being built now: the CLI itself. pydantic-ai-harness ships all the pieces a coding agent needs
(sandboxed filesystem + shell tools, repo context loading, planning, context compaction) but no
console entry point yet -- that's the gap we're closing, designed against your engine contract from
day one: prompt in, one-shot run, exit code out, MCP config consumed from the gateway so safe
outputs flow through the standard
safeoutputsserver.three questions where your answers change what we build:
behaviors.installation.package-managervalues other thannpmcompile clean butsilently emit no install step. we're fine on the
pre-agent-stepspath -- but a compile warningfor non-npm values would save the next Python/Rust engine author a confusing afternoon. want an
issue/PR for that?
the step summary, and
gh aw logs/gh aw auditreport zero tokens and turns (AI-creditaccounting through the proxy still works). we get why -- GitHub Agentic Workflow Engine Enhancement Proposal #20416 scoped declarative log parsing
out as a non-goal -- but that was before imported engines became the recommended route for third
parties. is there appetite for a hook here, e.g. a documented streaming-JSONL schema plus
parse_custom_log.cjspromoted to a real contract? we'd emit whatever schema you standardize,and we're happy to contribute the parser.
from the third-party agent guide?
not asking for a row in the engines table or any support commitment from you -- just a pointer
for people searching "how do I run X on gh-aw".
whatever shape this takes, we intend to maintain it long-term -- so if any assumption above looks
wrong, tell us now and we'll adjust before we ship :)