A starter scaffolded with `--framework mastra` accepted a chat message and
never answered. The run aborted server-side with `Thread <id> not found`.
`@ag-ui/mastra` writes the UI's shared state into Mastra working memory
before it streams a turn (`syncInputStateToWorkingMemory`). That write is
unguarded and never creates the thread, because it assumes the
resource-scoped store, which upserts. The starter was the one Mastra agent
in this repo that set `scope: "thread"`, which routes the same write to
thread metadata and requires the thread row to exist. On the first turn of a
conversation it does not, so `@mastra/memory` throws and the run dies before
the model is called.
Managed Intelligence made that certain rather than likely: the Intelligence
run handler swaps the client thread id for a platform-canonical one, which
the Mastra store has never seen. That is also why two different thread ids
appear in the same failure.
Verified against @mastra/core 1.41.0, @mastra/memory 1.0.1-alpha.1 and
@ag-ui/mastra 1.1.2: thread scope throws on a fresh thread, resource scope
writes, reads back, reaches the agent's system message, and stays per
conversation because the bridge derives the resource id from the thread id.
Every other Mastra agent here omits `scope`, so this aligns the starter with
them. The gate is a new contract test in the parity workflow's suite.
Left upstream: the adapter's local branch is still unguarded, so a developer
who chooses thread scope hits the same abort. Its remote branch already
creates the thread and retries. Worth a follow-up in ag-ui.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
State the Tailwind dependency and leave it there. A reader who skips the build
does not need the failure enumerated for them, and the symptoms stay on #4777
for anyone diagnosing from the other end.
The example tool-call card styles its header row with unprefixed Tailwind
utilities. Copied into a project that does not compile Tailwind, every class
resolves to nothing, the `<summary>` falls back to block layout, and the icons
and tool name stack in one column with the native `<details>` marker showing.
That is the layout reported in #4777, and nothing in the card says it depends
on a Tailwind build.
Add a file header recording the dependency, the two symptoms that identify it,
and the two ways out. The claude-sdk copies declare this file in
allowedDivergence, so they are annotated by hand; the rest come from
parity:sync.
The 1.70.0 repin left two copies of @copilotkit/shared in the AgentCore lambda: 1.70.0
nested under runtime, and 1.68.1 still hoisted at the top level, alongside a stale
@copilotkit/core 1.68.1.
runtime@1.70.0 pins shared to exactly 1.70.0, but the transitive @copilotkit/channels-*
0.9.0 packages ask for ^1.68.0, which the existing 1.68.1 resolution already satisfies.
A --package-lock-only bump has no reason to move a range that is already satisfied, so
npm hoists 1.68.1 for the channels packages and nests 1.70.0 under runtime. npm dedupe
does not collapse it; npm update on shared and core does.
Regenerating the lock from scratch also yields one clean copy, but sweeps 89 unrelated
packages with it -- @graphql-tools/executor 1.5.1 -> 2.0.0, @graphql-tools/utils 10 -> 11,
debug 2 -> 4, and a @types/express 5 -> 4 downgrade -- so it was rejected.
Verified: one copy of every @copilotkit and @ag-ui package in the lock afterwards, none
left on a 1.6x line, and npm install + tsc -p tsconfig.json exits 0.
Refs OSS-1029.
## What & why
The **"Frontend Tools"** demo (`setThemeColor`) silently fails in
`examples/integrations/adk`: asking "set the theme to green" makes the
agent reply *"I can only help with proverbs or the weather"* and nothing
recolors.
**Root cause:** the ADK agent's tools are static `[set_proverbs,
get_weather]`. `ag_ui_adk` only injects a run's forwarded client tools
(the frontend-registered `setThemeColor`) into the LLM's tool set when
the agent's `tools` include an **`AGUIToolset`** placeholder — it swaps
that for a `ClientProxyToolset` wired to `input.tools`. Without it,
`gemini-2.5-flash` never sees `setThemeColor` and declines. (No
CopilotKit ADK example currently includes `AGUIToolset`, and the docs
don't mention it.)
## Change
```python
from ag_ui_adk import ADKAgent, add_adk_fastapi_endpoint, AGUIToolset
...
tools=[set_proverbs, get_weather, AGUIToolset()],
```
Agent-side only; no prompt change needed.
## Testing
Verified **live** (real Gemini key) via the identical change in
`examples/integrations/adk-angular` (same `agent/main.py` + `ag_ui_adk`
adapter): "Set the theme to green" now recolors the panel; before the
fix the agent refused. Because the fix is agent-side and
framework-agnostic, and `setThemeColor` was already confirmed forwarded
in the run body, the React `adk` frontend + this agent behaves
identically.
## Related
- Companion to CopilotKit/CopilotKit#6097 (the new `adk-angular` example
carries the same fix).
- Discovered while validating #6097 by live-comparing Angular vs React
ADK behavior.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What
Converts `examples/integrations/agentcore` from unlocked
`requirements.txt` files to uv projects (`pyproject.toml` + `uv.lock`),
matching every other Python integration example in this repo.
## Why
The example already used uv as an *installer* — the agent images are
built from `ghcr.io/astral-sh/uv` and ran `uv pip install -r
requirements.txt` — but nothing was locked, so each image build
re-resolved transitive dependencies against whatever PyPI had that day.
That had already drifted into a hard break. `langgraph==1.0.10rc1`
resolved alongside a `langgraph-prebuilt` that reads `ExecutionInfo` off
`langgraph.runtime`, which 1.0.x does not export, so the LangGraph agent
raised `ImportError` at container start.
## The migration
- Both agents get a `pyproject.toml` + `uv.lock`; the Dockerfiles
install with `uv sync --locked` and run out of `/app/.venv`.
- LangGraph agent moves to `langgraph==1.1.6` / `langchain==1.2.15`, the
pair used by `examples/integrations/langgraph-python`, which resolves
the import failure. `langchain` was previously `>=0.3.0` while the code
uses the 1.x `create_agent` API.
- Four packages that shipped code imports directly were declared nowhere
and survived only as transitives: `boto3` (both agents, via
`agents/utils/ssm.py`), `PyJWT` (langgraph, via `agents/utils/auth.py`),
`langchain-core` (langgraph, via `tools/todos.py`), `botocore` (root,
via `scripts/utils.py`). All now declared; no resolved version changed.
- `aws-opentelemetry-distro` moves from a loose second `uv pip install`
into the locked set.
- The example root gets a project for the `scripts/` helpers. Their
`requirements.txt` listed the dependencies but nothing installed it, so
`uv run scripts/test-agent.py` — the command that script's own docstring
gives — failed on a missing `requests`.
- Deploy and local-dev scripts call `uv run` instead of bare `python3`;
preflight checks for `uv` rather than `python3`.
## Terraform
The docker-mode image hash read `patterns/<pattern>/requirements.txt`,
`patterns/utils`, a root-level `gateway/` and `tools/`, and a root
`pyproject.toml` — none of which exist here. `filesha256` on a missing
file is a plan-time error. Repointed at `agents/<pattern>` and
`agents/utils`, now hashing `pyproject.toml` and `uv.lock`.
The hash then had to exclude the virtualenv the migration creates:
`fileset(pattern_dir, "**/*.py")` saw 3114 files instead of 5, and the
computed hash differed depending on whether a developer had ever run the
agent locally — feeding `replace_triggered_by` and forcing a runtime
replacement. Measured: `5f9a98ef…` with a venv present vs `bacab1e1…`
without, on identical committed sources. The fix filters `.venv/` and
`venv/` and produces the clean-checkout digest in both cases.
## Review
Five review rounds plus a promotion audit, and nine defects this
migration introduced were found and fixed before merge. Each fix was
verified by running the thing, not by reading it:
- The image hash sweeping the local virtualenv (above).
- The undeclared direct dependencies (above).
- `scripts/test-agent.py` piped the child's output and never drained it,
deadlocking the agent, while the startup-timeout branch blocked forever
on a read — the only channel carrying uv's lockfile-drift error.
- `--local` treated any listener on port 8080 as the agent, so a foreign
process produced "Agent started successfully" while the real child died.
Adopting a running process is now explicit opt-in.
- The documented invocation contract had drifted across the two READMEs
and both scripts' usage text; a single reconciliation pass now owns all
of them, and every documented command was executed to confirm it works.
- The Terraform README named the CloudFormation deploy script, which
cannot read a Terraform deployment.
- Two `.env.example` entries parsed as their own trailing comment text
under Docker Compose.
- The build context shipped 898 MB of local-only artifacts (measured);
now 11 kB.
- Assorted comment and message inaccuracies, including a container env
block whose comment attributed a runtime-critical variable to uv.
## Repository hygiene
Two fixes the pre-merge gates surfaced rather than the review rounds:
- `oxfmt` on the example README and `tofu fmt` on the Terraform locals
file. The README break was introduced by this branch; the Terraform one
predates it but sits in a file this branch edits.
- The Terraform ignore rules were anchored to the top level, so the
provider cache `terraform init` writes beside every *nested* module was
fully stageable — a measured 834 MB one `git add -A` from being
committed. Switched to unanchored patterns, matching what this branch
already did for the virtualenv layout. Verified with `git check-ignore`
that the nested cache and lock file are now covered, tfstate and tfvars
still are, and no tracked file is caught by the wider patterns.
## Not addressed
Roughly 90 further findings are real but pre-existing and belong to four
follow-up subjects, listed in full in the review ledger:
- **Terraform module repair** — `terraform validate` fails on five
undeclared resources, so this module cannot plan at all. Zip mode
references an entry point and a packager directory that do not exist.
- **test-agent AG-UI correctness** — the request body fails
`RunAgentInput.model_validate` on both agents, and the response decoder
parses a pre-AG-UI format, so failures print nothing and exit 0.
- **README accuracy** — a `docs/` directory that does not exist, a wrong
Node floor, a teardown block whose second command never runs.
- **Deploy-script hardening** —
`infra-terraform/scripts/deploy-frontend.py` requires a Terraform output
nothing declares, so it exits 1 every run; the README now says so rather
than presenting it as a working path.
## Verification
Both images built for `linux/arm64` and the agent module imported inside
each, after every fix cycle. `uv lock --check` clean on all three
projects. Every documented command executed from its documented
directory. The virtualenv hash filter, the build-context reduction, the
pipe deadlock, the port-adoption fix and the env-file parsing were each
verified by measurement with before/after output. No repo CI job builds
or lints this example, so these local runs are the only coverage that
exists.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
CopilotKitIntelligence resolves apiUrl/wsUrl to the managed hosts when they are
omitted, and its own docstring says leaving both unset is always correct against
the managed service. Every starter's runtime route supplied
`?? "http://localhost:4201"` instead, so a managed reader who copied the block
got a runtime aimed at a local stack that is not running -- the failure the
starter's own .env.example warns about two files away.
Replace the fallbacks with the conditional spread these same starters already use
in channel-host.mts, so a self-hosted override still works and the managed
default applies when it is absent. Three .env.example files also set the values
uncommented, two of them directly under a comment telling the reader to leave
them unset; comment those out to match the other nineteen starters.
Guard both shapes in validate-intelligence-env-names.ts, which already polices
the canonical Intelligence key name and hosts and runs unfiltered on every PR.
The rule is the pattern rather than the literal, so a staging host substituted
for localhost fails the same way. Local e2e harnesses and demo stacks that
genuinely target a local deployment are allowlisted with their reasons.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The marked block that wires managed Intelligence is the region a hosted reader
copies verbatim, and nothing checked it. Both gaps were deliberate: the parity
manifest lists `src/app/api/copilotkit/**` under `allowedDivergence` for every
instance it tracks, and no `docker-compose.test.yml` sets
`COPILOTKIT_LICENSE_TOKEN`, so every smoke-tested starter takes the else arm and
the `intelligence:` arm has never run in CI.
The cost was already visible. The block's code was byte-identical in 21 of 22
starters, but its warning comment had drifted into five variants and the two
`ms-agent-framework-*` starters shipped the `demo-user` stub with no warning at
all. That drift is how the localhost default of OSS-981 survived in all 22
copies at once.
Add `scripts/validate-intelligence-wiring-block.ts`, which greps the opening
marker, compares every site against the north-star starter, and fails on the
first line that differs. Two normalisations keep it usable: the block is
dedented, because `agentcore` nests it deeper, and the else arm's runner name is
masked, because `agentcore` runs `AgentCoreRunner` in front of a Bedrock session
where an in-process runner has nothing to run. Everything else, comment text
included, must match to the byte.
Then unify the warning at all 22 sites on the fullest wording, which also says
the id must exist in Intelligence or thread operations can fail.
The check passes on day one, so it is a ratchet rather than a migration. It is a
shape gate, not a content gate: 22 identically wrong copies still pass. What it
guarantees is that a fix reaches all of them or none.
Not covered: enrolling the `intelligence:` arm in the smoke path. That needs a
license token in CI and a reachable endpoint from the compose network, and is
tracked separately.
CopilotKitIntelligence resolves apiUrl/wsUrl to the managed hosts when they are
omitted, and its own docstring says leaving both unset is always correct against
the managed service. Every starter's runtime route supplied
`?? "http://localhost:4201"` instead, so a managed reader who copied the block
got a runtime aimed at a local stack that is not running -- the failure the
starter's own .env.example warns about two files away.
Replace the fallbacks with the conditional spread these same starters already use
in channel-host.mts, so a self-hosted override still works and the managed
default applies when it is absent. Three .env.example files also set the values
uncommented, two of them directly under a comment telling the reader to leave
them unset; comment those out to match the other nineteen starters.
Guard both shapes in validate-intelligence-env-names.ts, which already polices
the canonical Intelligence key name and hosts and runs unfiltered on every PR.
The rule is the pattern rather than the literal, so a staging host substituted
for localhost fails the same way. Local e2e harnesses and demo stacks that
genuinely target a local deployment are allowlisted with their reasons.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Terraform ignore rules were anchored to `infra-terraform/…`, which matches
only the root provider cache. `terraform init` writes one next to every module,
and the nested copies are the large ones: 834MB under
infra-terraform/modules/backend/ was fully stageable, one `git add -A` from
being committed.
Switch the two cache patterns to unanchored `**/` forms, matching what this
branch already did for the `venv/` layout. Verified with git check-ignore: the
root cache, the nested cache and the nested lock file are all ignored now,
tfstate and tfvars still are, and no tracked file (checked against
modules/backend/locals.tf) is caught by the widened patterns.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Prerequisites table in examples/integrations/agentcore/README.md picked up
a uv row whose URL is wider than the existing column padding, leaving the table
unaligned against oxfmt (the repo formatter covers .md — see the lint-fix glob
in lefthook.yml). Re-run oxfmt --write on that one file.
locals.tf fails tofu fmt on a pre-existing misalignment in the Lambda
source-path block that this branch did not introduce; since the file is already
in this branch's diff, align it here so every changed .tf file passes
tofu fmt -check. Scoped to locals.tf only — modules/backend/copilotkit_runtime.tf
has the same class of debt but is out of this diff and is left alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
copilotkit-qa-bot[bot]