mirror of
https://github.com/microsoft/agent-framework.git
synced 2026-06-16 21:04:09 +08:00
Eduard van Valkenburg
9f14a0f33f
* Add ADR for Python ContextMiddleware unification * Add session serialization/deserialization design to ADR * Add Related Issues section mapping to ADR * Update session management: create_session, get_session_by_id, agent.serialize_session * ADR: Add hooks alternative, context compaction discussion, and PR feedback - Add Option 3: ContextHooks with before_run/after_run pattern - Add detailed pros/cons for both wrapper and hooks approaches - Add Open Discussion section on context compaction strategies - Clarify response_messages is read-only (use AgentMiddleware for modifications) - Add SimpleRAG examples showing input-only filtering - Clarify default storage only added when NO middleware configured - Add RAGWithBuffer examples for self-managed history - Rename hook methods to before_run/after_run * ADR: Restructure and add .NET comparison - Add class hierarchy clarification for both options - Merge detailed design sections (side-by-side comparison) - Move detailed design before decision outcome - Move compaction discussion after decision - Add .NET implementation comparison (feature equivalence) - Update .NET method names to match actual implementation - Rename hook methods to before_run/after_run - Fix storage context table for injected context * tweaks * fix smart load * ADR: Add naming discussion note for ContextHooks - Note that class and method names are open for discussion - Add alternative method naming options table - Include invoking/invoked as option matching current Python and .NET * Update context middleware design: remove smart mode, add attribution filtering - Remove smart mode for load_messages (now explicit bool, default True) - Add attribution marker in additional_properties for message filtering - Update validation to warn on multiple or zero storage loaders - Add note about ChatReducer naming from .NET - Note that attribution should not be propagated to storage * Add Decision 2: Instance Ownership (instances in session vs agent) - Option A: Instances in Session (current proposal) - Option B: Instances in Agent, State in Session - B1: Simple dict state with optional return - B2: SessionState object with mutable wrapper - Updated examples to use Hooks pattern (before_run/after_run) - Added open discussion on hook factories in Option B model * Update ADR: Choose ContextPlugin with before_run/after_run and Option B1 Decision outcomes: - Option 3 (Hooks pattern) with ContextPlugin class name - Methods: before_run/after_run - Option B1: Instances in Agent, State in Session (simple dict) - Whole state dict passed to plugins (mutable, no return needed) - Added trust note: plugins reason over messages, so they're trusted by default Status changed from proposed to accepted. * Add agent and session params to before_run/after_run methods Signature now: before_run(agent, session, context, state) * Remove ContextPluginRunner, store plugins directly on agent Simpler design: agent stores Sequence[ContextPlugin] and calls before_run/after_run directly in the run method. * Update workplan to 2 PRs for simpler review * updated doc * Refine ADR: serialization, ownership, decorators, session methods, exports - Add to_dict()/from_dict() on AgentSession with 'type' discriminator - Present serialization as Option A (direct) vs Option B (through agent) - Rewrite ownership section as 2x2 matrix (orthogonal decision) - Move Instance Ownership Options before Decision Outcome - Fix get_session to use service_session_id, split from create_session - Add decorator-based provider convenience API (@before_run/@after_run) - Add _ prefix naming strategy for all PR1 types (core + external) - Constructor compatibility table for existing providers - Add load_messages=False skip logic to all agent run loops - Clarify abstract vs non-abstract in execution pattern samples - Update auto-provision: trigger on conversation_id or store=True - Document root package exports (ContextProvider, HistoryProvider, etc.) - Rename section heading to 'Key Design Considerations' * Rename ADR to 0016-python-context-middleware.md * Fix broken link: #3-unified-storage-middleware → #3-unified-storage
9f14a0f33f
·
2026-02-10 04:50:54 +00:00
History
Architectural Decision Records (ADRs)
An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architectural Decision Record (ADR) captures a single AD and its rationale.
For more information see
How are we using ADRs to track technical decisions?
- Copy docs/decisions/adr-template.md to docs/decisions/NNNN-title-with-dashes.md, where NNNN indicates the next number in sequence.
- Check for existing PR's to make sure you use the correct sequence number.
- There is also a short form template docs/decisions/adr-short-template.md
- Edit NNNN-title-with-dashes.md.
- Status must initially be
proposed - List of
decidersmust include the github ids of the people who will sign off on the decision. - The relevant EM and architect must be listed as deciders or informed of all decisions.
- You should list the names or github ids of all partners who were consulted as part of the decision.
- Keep the list of
decidersshort. You can also list people who wereconsultedorinformedabout the decision.
- Status must initially be
- For each option list the good, neutral and bad aspects of each considered alternative.
- Detailed investigations can be included in the
More Informationsection inline or as links to external documents.
- Detailed investigations can be included in the
- Share your PR with the deciders and other interested parties.
- Deciders must be listed as required reviewers.
- The status must be updated to
acceptedonce a decision is agreed and the date must also be updated. - Approval of the decision is captured using PR approval.
- Decisions can be changed later and superseded by a new ADR. In this case it is useful to record any negative outcomes in the original ADR.