From 2fc6ea9bde3fca0139ac6be084a823befe4d5990 Mon Sep 17 00:00:00 2001 From: NingLin Liu Date: Wed, 4 Nov 2026 08:32:16 +0800 Subject: [PATCH] docs: fix spelling typos in decision records --- docs/decisions/0001-agent-run-response.md | 4 ++-- docs/decisions/0008-python-subpackages.md | 2 +- docs/decisions/0019-python-context-compaction-strategy.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/decisions/0001-agent-run-response.md b/docs/decisions/0001-agent-run-response.md index e8a5ac0776a..01f8dec506c 100644 --- a/docs/decisions/0001-agent-run-response.md +++ b/docs/decisions/0001-agent-run-response.md @@ -324,7 +324,7 @@ public string? ModelId { get; set; } ``` - **PROS**: Agent response types can evolve separately. Types can still resemble MEAI response types to ensure a fimilar experience for developers. -- **CONS**: No automatic inheritence of new properties from MEAI. (this might also be a pro) +- **CONS**: No automatic inheritance of new properties from MEAI. (this might also be a pro) ## Long Running Processes Options @@ -355,7 +355,7 @@ public class ChatFinishReason ``` - **PROS**: Fits well into existing `ChatResponse` design. -- **CONS**: More complex for users to extract the required long running result (can be mitigated with extenion methods) +- **CONS**: More complex for users to extract the required long running result (can be mitigated with extension methods) ### Option 2: Add another property on responses for AgentRun diff --git a/docs/decisions/0008-python-subpackages.md b/docs/decisions/0008-python-subpackages.md index fc2db44f807..5ae4b94ea00 100644 --- a/docs/decisions/0008-python-subpackages.md +++ b/docs/decisions/0008-python-subpackages.md @@ -66,7 +66,7 @@ The goal is to design a subpackage structure for the Python agent framework that - makes developer package management more complex, because that meta-extra will include both GA and non-GA packages, so during dev they could use that, but then during prod they have to figure out which one they actually need and make a change in their dependencies, leading to mismatches between dev and prod. 6. Make all imports happen from `agent_framework.connectors` (or from two or three groups `agent_framework.chat_clients`, `agent_framework.context_providers`, or something similar) while the underlying code comes from different packages. * Pros: - - best developer experience, since all imports are from the same place and it is easy to find what you need, and we can raise a meaningfull error with which extra to install. + - best developer experience, since all imports are from the same place and it is easy to find what you need, and we can raise a meaningful error with which extra to install. - easier for users to find and install the right package. * Cons: - larger overhead in maintaining the `__init__.py` files that do the lazy loading and error handling. diff --git a/docs/decisions/0019-python-context-compaction-strategy.md b/docs/decisions/0019-python-context-compaction-strategy.md index 1cdd15bb021..7130aafd7e1 100644 --- a/docs/decisions/0019-python-context-compaction-strategy.md +++ b/docs/decisions/0019-python-context-compaction-strategy.md @@ -646,7 +646,7 @@ agent = client.create_agent( There are two ways we can do this: 1. Before writing to storage in `after_run`, compaction is called on the new messages, - combined with: a new `compact` method, that reads the full history, calls the compaction strategy with the full history, then writes the compacted result back to storage (also requires a `overwrite` flag on the `save_messages` method). This makes removing old messages from storage a explicit action that the user initiaties instead of being implicitly triggered by `after_run` writes, but it also means compaction strategies only see new messages instead of the full history (unless they read it themselves), the `compact` method could then also have a override for the strategy to use (and/or the tokenizer in case of Variant E1/E2/F1/F2). + combined with: a new `compact` method, that reads the full history, calls the compaction strategy with the full history, then writes the compacted result back to storage (also requires a `overwrite` flag on the `save_messages` method). This makes removing old messages from storage a explicit action that the user initiates instead of being implicitly triggered by `after_run` writes, but it also means compaction strategies only see new messages instead of the full history (unless they read it themselves), the `compact` method could then also have a override for the strategy to use (and/or the tokenizer in case of Variant E1/E2/F1/F2). ```python class HistoryProvider(ContextProvider):