[Control Plane] Track custom metadata added to context of exec endpoints

[pocesar]

Summary

Instead of adding a new field to the pydantic model for reasoner and constantly passing down the same data over and over (say, user_id, profile_url), it would be great if any type of data would be kept by the control plane and be accessed by any reasoner, skill or different agents without doing manual prop drilling.

Proposed solution

The ExecutionContext would allow to resolve any data that came to the /exec endpoint in the context payload part and store it. Calling get_current_context().some_custom_field would match any of the custom attached metadata and retrieve it. Similar to how memory works but static data that is available throughout the full execution.

Alternatives considered

Keep adding more fields to pydantic models and keep passing down at every app.call() callsite, manually enriching the payload to avoid repetition

Additional context

Sometimes you want to give information that won't be useful to AF but is when forwarding to another service (like Claude or OpenAI). Those extra fields can make or break a complex workflow

[AbirAbbas]

Triage

Classification: feature ✓
Suggested labels: enhancement

Likely affected files:

• ./reasoners/models.py (matched: model, reasoner, reasoner, models)
• ./reasoners/init.py (matched: reasoner, reasoner)
• ./reasoners/conversational.py (matched: reasoner, reasoner)
• ./reasoners/helpers.py (matched: reasoner, reasoner)
• ./reasoners/repo_config.py (matched: reasoner, reasoner)

---

Triage by github-buddy

[AbirAbbas]

Two halves.

What exists today: #998 documents the context contract, including that it's forwarded to the reasoner the control plane dispatches to but never delivered to a local agent node, and it isn't propagated through app.call(). For run-static data right now the working pattern is the workflow-scoped memory (app.memory with the run id as scope): set once in the entrypoint, read anywhere in the run.

Why I don't want to make context itself propagate, which is the obvious fix: it's part of the replay/dedupe key (propagating it would change replay matching for every existing restart), it's forwarded verbatim to external ARD endpoints (auto-propagated user data would leak to third parties), and it carries reserved keys — provider, model_provider, llm_endpoint, ARD operation — so a propagated provider would re-gate LLM routing on every child call.

The shape I'd propose instead: a distinct run-scoped baggage bag, set once at run start, persisted in workflow_runs.metadata under its own namespace, injected by the control plane into every dispatch in the run, and exposed by all three SDKs as get_current_context().baggage (bounded size, string values). @santoshkumarradha this is a new cross-SDK wire concept, so it's yours to green-light; #944's run namespace lands in the same column and is designed not to collide with it.

[santoshkumarradha]

@AbirAbbas Yes, I would say the ideal for this is using memory scope as this exactly behaves as such with ttl as well and is more indeed designed to hold much larger context (as its handled as memory) than a context column can I think. But would be interesting to see what prevents @pocesar from using the memory scoped to run

EDIT: Although we should mull over this a bit because i think this might be bit different than application state and maybe baggage indeed makes sense. Lets DB

[pocesar]

@santoshkumarradha the reason is easy to propagate to other deployments, since there are multiple nodes and reasoners in separate machines that, without manual injection of the memory keys, wouldn't be able to understand the context. For example, the orchestrator approach fans out multiple requests, collect and return. This means that the other agents would be become coupled to the orchestrator and depends on it's initial "set memory to this value" skill / reasoner step. Calling those "sub agents" (for a lack of better name) would require passing down the prop manually if the memory wasn't set.

But reusing the internal memory machinery for automatically setting the baggage makes a lot of sense, maybe an unique symbol that won't conflict with day-to-day field names