feat(langchain): add LangChain export adapter & runner with multi-provider support

[AJAmit17]

What

Add a LangChain export adapter and runner to gitagent. This allows exporting any gitagent agent definition to a runnable LangChain Python script, and executing it directly via the CLI.

Key features:

• Provider support — auto-detects LLM provider from model name (gpt-*, o1-→ OpenAI; claude- → Anthropic). Unsupported models fail with a clear error message
• Modern LangChain API — uses init_chat_model(), create_agent(), @tool decorator. No deprecated imports (AgentExecutor, ConversationBufferMemory, provider-specific classes)
• Full manifest mapping — tools, sub-agents (mapped as delegate @tool functions), memory, knowledge docs (always_load), compliance constraints, delegation instructions, skills
• Auto venv setup — runner creates a persistent venv at ~/.gitagent/langchain-venv, installs required packages automatically (Windows + Mac/Linux supported)
• Provider-aware runner — checks correct env var (OPENAI_API_KEY or ANTHROPIC_API_KEY) before execution

Why

LangChain is one of the most widely used agent frameworks. Supporting it as an export target makes gitagent useful to a much larger audience and was explicitly listed as a wanted adapter in CONTRIBUTING.md.

Closes #2

How Tested

• npm run build passes
• gitagent validate passes on example agents
• Manual testing on Windows 11, Node 22, Python 3.12:
  1. Exported all 5 examples via: gitagent export -f langchain -d examples/<name> -o <file>
  2. Python ast.parse() syntax validation passed on all 5 generated scripts
  3. End-to-end runs tested:
     • lyzr-agent with gpt-4.1 + OPENAI_API_KEY
     • full with claude-opus-4-6 + ANTHROPIC_API_KEY
• CLI runner: gitagent run -d examples/minimal --adapter langchain
• Prompt flag: gitagent run -d examples/lyzr-agent --adapter langchain -p "Summarize quantum computing"

Checklist

• My code follows the existing style of this project
• I have added/updated tests (if applicable)
• I have updated documentation (if applicable)
• I have read the CONTRIBUTING.md

[shreyas-lyzr]

This is the oldest open PR (March 4). The LangChain adapter generates Python code using the Agents SDK. A few issues:

1. Massive scope — 602 lines, touches README, multiple files. Should be split: adapter first, runner second.
2. Runner modifies git.ts — adds LangChain auto-detection to the git runner, which is risky scope creep.
3. No tests — all other recent adapter PRs include tests.
4. Generated Python uses openai.agents — this is the OpenAI Agents SDK, not LangChain. The PR title says LangChain but the code generates OpenAI Agents SDK Python. Misleading.

Please clarify: is this a LangChain adapter or an OpenAI Agents SDK adapter? The generated code doesn't use LangChain at all.

[AJAmit17]

This is the oldest open PR (March 4). The LangChain adapter generates Python code using the Agents SDK. A few issues:

1. Massive scope — 602 lines, touches README, multiple files. Should be split: adapter first, runner second.
2. Runner modifies git.ts — adds LangChain auto-detection to the git runner, which is risky scope creep.
3. No tests — all other recent adapter PRs include tests.
4. Generated Python uses openai.agents — this is the OpenAI Agents SDK, not LangChain. The PR title says LangChain but the code generates OpenAI Agents SDK Python. Misleading.

Please clarify: is this a LangChain adapter or an OpenAI Agents SDK adapter? The generated code doesn't use LangChain at all.

Hi @shreyas-lyzr, thanks for the detailed review!

Just to clarify — this is a LangChain adapter, not an OpenAI Agents SDK adapter. I believe there may have been a mismatch in how it was tested.

If you run:

npm run build
node dist/index.js export --format langchain -d examples/minimal -o test.py

the generated Python clearly uses LangChain APIs (create_agent, init_chat_model, @tool) with imports from langchain.*, not openai.agents.

Key points:

• Tests are included and passing (langchain.test.ts)
• The runner creates/reuses a virtualenv (gitagent-env) and installs langchain + langchain-openai before execution

Quick run (end-to-end)

npm run build
export OPENAI_API_KEY=your-key
node dist/index.js run -d examples/minimal --adapter langchain -p "Hello"

(Requires OPENAI_API_KEY to be set)

The confusion might come from using OpenAI models as a provider via LangChain, but the framework itself is fully LangChain-based.

Based on your feedback:

• Moved LangChain-related changes out of git.ts into run.ts
• Added tests
• Included adapter docs for clarity

Do let me know if any improvements are needed to these changes I’ve made 👍

[shreyas-lyzr]

Apologies for the very long review delay on this — March was a busy stretch, and this sat far longer than it deserved.

State of play: CI is green on Node 18/20/22, the diff is large (1770/+, 4/-), and the PR predates several refactors in src/commands/export.ts and src/commands/run.ts (notably the duplicate-requiredOption cleanup, the kiro/gitclaw adapter additions, and the new --workspace flag in #71).

What I'd like to see before this can land:

1. Rebase on main. With fix: resolve duplicate option registration in export and import commands #54/feat: implement extends resolution, --force update, and parent merge in export #55 closed and the export/run command files now in their post-rebrand shape (@open-gitagent/gapman, kiro/gitclaw cases, etc.), a rebase will let me read a clean diff. Right now the conflicts will overwhelm review.
2. Confirm scope of the runner. Is runWithLangChain invoking the user's installed Python LangChain (subprocess) or shipping a JS LangChain runtime? Both are valid choices; the doc page should be explicit.
3. Multi-provider switching. The PR title mentions multi-provider support — for OpenAI/Anthropic/etc. via LangChain. Worth a note in docs/adapters/langchain.md about provider precedence (env vars vs model.preferred vs agent.yaml: provider) and what happens when they disagree.
4. Fidelity profile entry. When this lands I'd like a row in the paper's adapter fidelity matrix (paper/tables/fidelity-matrix.csv). I can do this in a follow-up — just flagging.

Brutally honest: the code itself, on the parts that don't conflict, is well-structured (separate langchain.ts adapter + langchain.ts runner + dedicated test file + docs page). Nothing in the architecture concerns me. The blocker is purely scope-management — landing 1770 lines that conflict with the current main is risky without a rebase.

Plan:

• Please rebase on main when you have a moment.
• I'll re-review immediately after (real promise this time).
• If the rebase is large enough that it's easier to start fresh, I'd accept a new PR with you as author and link this one as the original — your authorship credit stays.

Thank you for the work and the patience.