dex-agents 0.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,105 @@
1
+ # License
2
+
3
+ Copyright (c) 2026 Super Durable, Inc.
4
+
5
+ Portions of this software are licensed as follows:
6
+
7
+ - Legacy Materials remain under their original licenses as described in
8
+ `LEGACY_NOTICES.md`.
9
+ - Third-Party Materials remain under the licenses provided by their owners.
10
+ - The `docs/` and `examples/` directories are not licensed under the
11
+ Sustainable Use License and retain their existing licensing status.
12
+ - All other material owned or licensable by Super Durable, Inc. is available
13
+ under the Sustainable Use License below.
14
+
15
+ See `LEGACY_NOTICES.md` for the applicable legacy and third-party notices.
16
+
17
+ ## Sustainable Use License
18
+
19
+ Version 1.0
20
+
21
+ ### Acceptance
22
+
23
+ By using the software, you agree to all of the terms and conditions below.
24
+
25
+ ### Copyright License
26
+
27
+ The licensor grants you a non-exclusive, royalty-free, worldwide,
28
+ non-sublicensable, non-transferable license to use, copy, distribute, make
29
+ available, and prepare derivative works of the software, in each case subject
30
+ to the limitations below.
31
+
32
+ ### Limitations
33
+
34
+ You may use or modify the software only for your own internal business purposes
35
+ or for non-commercial or personal use. You may distribute the software or
36
+ provide it to others only if you do so free of charge for non-commercial
37
+ purposes. You may not alter, remove, or obscure any licensing, copyright, or
38
+ other notices of the licensor in the software. Any use of the licensor's
39
+ trademarks is subject to applicable law.
40
+
41
+ ### Patents
42
+
43
+ The licensor grants you a license, under any patent claims the licensor can
44
+ license, or becomes able to license, to make, have made, use, sell, offer for
45
+ sale, import and have imported the software, in each case subject to the
46
+ limitations and conditions in this license. This license does not cover any
47
+ patent claims that you cause to be infringed by modifications or additions to
48
+ the software.
49
+
50
+ If you or your company make any written claim that the software infringes or
51
+ contributes to infringement of any patent, your patent license for the software
52
+ granted under these terms ends immediately. If your company makes such a claim,
53
+ your patent license ends immediately for work on behalf of your company.
54
+
55
+ ### Notices
56
+
57
+ You must ensure that anyone who gets a copy of any part of the software from
58
+ you also gets a copy of these terms. If you modify the software, you must
59
+ include in any modified copies of the software a prominent notice stating that
60
+ you have modified the software.
61
+
62
+ ### No Other Rights
63
+
64
+ These terms do not imply any licenses other than those expressly granted in
65
+ these terms.
66
+
67
+ ### Termination
68
+
69
+ If you use the software in violation of these terms, such use is not licensed,
70
+ and your license will automatically terminate. If the licensor provides you
71
+ with a notice of your violation, and you cease all violation of this license no
72
+ later than 30 days after you receive that notice, your license will be
73
+ reinstated retroactively. However, if you violate these terms after such
74
+ reinstatement, any additional violation of these terms will cause your license
75
+ to terminate automatically and permanently.
76
+
77
+ ### No Liability
78
+
79
+ As far as the law allows, the software comes as is, without any warranty or
80
+ condition, and the licensor will not be liable to you for any damages arising
81
+ out of these terms or the use or nature of the software, under any kind of
82
+ legal claim.
83
+
84
+ ### Definitions
85
+
86
+ The "licensor" is the entity offering these terms.
87
+
88
+ The "software" is the software the licensor makes available under these terms,
89
+ including any portion of it.
90
+
91
+ "You" refers to the individual or entity agreeing to these terms.
92
+
93
+ "Your company" is any legal entity, sole proprietorship, or other kind of
94
+ organization that you work for, plus all organizations that have control over,
95
+ are under the control of, or are under common control with that organization.
96
+ Control means ownership of substantially all the assets of an entity, or the
97
+ power to direct its management and policies by vote, contract, or otherwise.
98
+ Control can be direct or indirect.
99
+
100
+ "Your license" is the license granted to you for the software under these
101
+ terms.
102
+
103
+ "Use" means anything you do with the software requiring your license.
104
+
105
+ "Trademark" means trademarks, service marks, and similar rights.
@@ -0,0 +1,403 @@
1
+ Metadata-Version: 2.4
2
+ Name: dex-agents
3
+ Version: 0.1.0
4
+ Summary: Durable agent sessions for Dex, shared by the Dex agent framework adapters
5
+ Author: Super Durable
6
+ License-Expression: LicenseRef-Sustainable-Use-1.0
7
+ License-File: LICENSE
8
+ Classifier: Development Status :: 3 - Alpha
9
+ Classifier: Programming Language :: Python :: 3
10
+ Classifier: Programming Language :: Python :: 3 :: Only
11
+ Classifier: Typing :: Typed
12
+ Requires-Dist: dex-python-sdk==1.30.0
13
+ Requires-Python: >=3.11
14
+ Project-URL: Homepage, https://github.com/superdurable/dex/tree/main/agents/python/core
15
+ Project-URL: Repository, https://github.com/superdurable/dex
16
+ Project-URL: Changelog, https://github.com/superdurable/dex/blob/main/agents/CHANGELOG.md
17
+ Description-Content-Type: text/markdown
18
+
19
+ # dex-agents
20
+
21
+ `dex-agents` (import `dex_agents`) is the Python core of the Dex agent
22
+ framework adapters. It provides one durable agent session Flow,
23
+ `AgentSessionFlow`, and the `AgentFrameworkRunner` contract that each
24
+ framework adapter implements. The plan is
25
+ [agent-framework-adapters.md](https://github.com/superdurable/dex/blob/main/docs/design/plan/agent-framework-adapters.md).
26
+
27
+ One Flow execution is one agent session; the Flow ID is the session ID. The
28
+ session runs in **Step mode**: every model call is one `RunModel` Step, and
29
+ every tool call, READ included, is its own Step. The tool call Steps of one
30
+ model response run in parallel, and `ResumeTurn` waits for their results
31
+ before the next model call. Each call therefore has its own retry policy,
32
+ timeout, failure route, history entry, and Dex Web node, and a crash repeats
33
+ at most the one call that was running.
34
+
35
+ ## Installation
36
+
37
+ Applications usually install an adapter, which brings in this package. To
38
+ build a runner of your own, install the core directly. It needs Python 3.11 or
39
+ later and requires the released `dex-python-sdk==1.30.0`:
40
+
41
+ ```bash
42
+ pip install dex-agents
43
+ ```
44
+
45
+ `dex_agents.testing` ships in the same wheel, so an adapter's integration
46
+ tests can start a private engine and Worker processes.
47
+
48
+ Develop the package inside this repository with uv 0.12.2. The adapters in
49
+ this repository resolve it from `../core` by path through
50
+ `[tool.uv.sources]`; their published wheels require it from PyPI instead:
51
+
52
+ ```bash
53
+ cd agents/python/core
54
+ uv sync --locked
55
+ DEXCLI=/path/to/dexcli ./ci.sh
56
+ ```
57
+
58
+ An adapter requires `dex-agents==<same version>`. All agents packages share
59
+ one version line; see the
60
+ [compatibility table](https://github.com/superdurable/dex/blob/main/agents/README.md#versions-and-compatibility).
61
+
62
+ ## Running an agent
63
+
64
+ ```python
65
+ from dex import AsyncClient, AsyncWorker, BlobCacheConfig, ClientOptions, Registry
66
+ from dex import WorkerOptions, open_blob_cache
67
+ from dex_agents import AgentSessionClient, AgentSessionFlow, AgentSessionOptions
68
+ from dex_agents import ToolEffect, ToolPolicy
69
+
70
+ flow = AgentSessionFlow(
71
+ MyFrameworkRunner(agent),
72
+ flow_type="TriageAgent",
73
+ options=AgentSessionOptions(
74
+ tool_policies={"search_tickets": ToolPolicy(ToolEffect.READ)},
75
+ ),
76
+ )
77
+ registry = Registry([flow], allow_async_handlers=True)
78
+ cache = open_blob_cache(BlobCacheConfig(".dex-cache", 64 * 1024 * 1024))
79
+ worker = AsyncWorker(registry, cache, WorkerOptions(server_address="localhost:8801"))
80
+ client = AsyncClient(registry, cache, ClientOptions(server_address="localhost:8801"))
81
+
82
+ sessions = AgentSessionClient(client, flow)
83
+ await sessions.start_session("session-42", "Find my open tickets")
84
+ snapshot = await sessions.get_agent_snapshot("session-42")
85
+ ```
86
+
87
+ Register one `AgentSessionFlow` per agent, each with its own `flow_type`. All
88
+ Steps are `async`, so the Registry needs `allow_async_handlers=True` and an
89
+ `AsyncWorker` serves it. Tool calls run as parallel Steps, so give the Worker
90
+ enough task slots (`PullWorkerOptions.max_concurrent_tasks`) for the largest
91
+ batch of tool calls a model makes. A session never completes by itself; it
92
+ waits for the next user message after every turn. Stop it with
93
+ `AsyncClient.stop_flow`.
94
+
95
+ ## The runner contract
96
+
97
+ An adapter implements three methods. The session calls them from Steps, so
98
+ each call may run again after a crash or retry. Keep the runner stateless
99
+ between calls and derive everything from the arguments.
100
+
101
+ ```python
102
+ class AgentFrameworkRunner(Protocol):
103
+ def build_user_message(self, text: str) -> FrameworkMessage: ...
104
+ async def run_model_step(self, turn: AgentTurnContext) -> AgentTurnOutcome: ...
105
+ async def execute_deferred_tool_call(self, call: DeferredToolExecution) -> ToolExecutionResult: ...
106
+ ```
107
+
108
+ `AgentTurnOutcome` is `TurnCompleted | ToolCallsRequested`.
109
+
110
+ ### `build_user_message(text)`
111
+
112
+ Return `FrameworkMessage(role=MessageRole.USER, framework_item=..., text=text)`.
113
+ The session stores it as the turn's first message before the first
114
+ `RunModel`. `RecordTurnFailure` also calls it for the turn-failure note. Any
115
+ other role fails the Step.
116
+
117
+ ### `run_model_step(turn)`
118
+
119
+ The framework makes **at most one model call** per `run_model_step`, and
120
+ stops before it runs any tool it can defer. `AgentTurnContext` carries
121
+ committed state:
122
+
123
+ | Field | Meaning |
124
+ | --- | --- |
125
+ | `flow_id`, `turn_id`, `attempt` | Session ID, `"turn-<n>"`, and the one-based `RunModel` attempt. |
126
+ | `messages` | Every stored `AgentMessage` in sequence order. The last user message belongs to this turn. |
127
+ | `framework_run_state` | `None` for the turn's first model call; otherwise the value from this turn's last `ToolCallsRequested`. `is_resuming` tests it. |
128
+ | `tool_calls` | Every `AgentToolCall` record of this turn by tool call ID. When `RunModel` runs, every record is final. `recorded_tool_call(id)` reads one. |
129
+ | `resolve_tool_policy(name, framework_effect=None)` | The policy for a tool: explicit policy, else framework metadata, else `default_tool_effect`. |
130
+ | `events` | `AgentEventWriter` bound to the turn, Step execution, and attempt: `write_text_delta`, `write_reasoning_delta`, `write_tool_call_started`, `write_tool_call_finished`, `write_event`. Safe to call from any thread; writes after the call returns are dropped. |
131
+ | `heartbeat()` | Records liveness. The session already heartbeats every 20 seconds in the background. |
132
+
133
+ A runner must:
134
+
135
+ 1. Without run state, rebuild framework input from each message's
136
+ `framework_item`. With run state, restore the framework from it and give
137
+ every tool call the result from its final record instead of running the
138
+ tool. `describe_tool_call_outcome(record)` renders the model-visible text.
139
+ A framework with a native rejection API may pass `record.rejection_message`
140
+ there instead.
141
+ 2. Let the framework make one model call.
142
+ 3. If the response asks for tools, return `ToolCallsRequested(framework_run_state,
143
+ tool_calls, usage)` with one `DeferredToolCall(tool_call_id, tool_name,
144
+ arguments, policy)` per call, in model order. Get each `policy` from
145
+ `turn.resolve_tool_policy(name, framework_effect)`; pass `framework_effect`
146
+ when the framework exposes metadata, such as MCP `readOnlyHint` (`READ`) or
147
+ `idempotentHint` (`IDEMPOTENT_WRITE`). `framework_run_state` must be
148
+ non-empty and must continue the turn after the tools. Tool call IDs must be
149
+ non-empty, contain no `/`, and be unique within one turn; IDs may repeat in
150
+ later turns, because the idempotency key includes the turn ID.
151
+ 4. If the response is the final answer, return `TurnCompleted(new_messages,
152
+ usage)`. `new_messages` holds every item the turn produced after its user
153
+ message, in order, across all of its model calls: model output, tool
154
+ requests, tool results, and the final answer. The session appends them in
155
+ one commit. Nothing is appended while tool calls run.
156
+ 5. Report `usage` for this model call only. The session adds it to the session
157
+ total.
158
+ 6. Never run a tool inside `run_model_step`, unless the framework cannot defer
159
+ it. Document such tools as at-least-once: a `RunModel` retry runs them
160
+ again.
161
+
162
+ Any exception fails the attempt. `RunModel` retries up to three attempts
163
+ within 30 minutes, rerunning only this one model call, then routes to
164
+ `RecordTurnFailure`. Each attempt has a 15 minute timeout.
165
+
166
+ When a failed turn already has final tool call records, `RecordTurnFailure`
167
+ stores one note before it deletes them, built with `build_user_message`, so
168
+ the next turn's model does not repeat a write. `build_turn_failure_note`
169
+ renders it, one line per record in `deferral_order`:
170
+
171
+ ```text
172
+ [Dex] The previous turn failed after these tool calls ran:
173
+ - <tool_name> <arguments> -> <status>: <describe_tool_call_outcome(record)>
174
+ Do not repeat these tool calls unless the user asks again.
175
+ ```
176
+
177
+ ### `execute_deferred_tool_call(call)`
178
+
179
+ `DeferredToolExecution` carries `flow_id`, the approved `tool_call` record,
180
+ `idempotency_key` (`"<flow_id>/<turn_id>/<tool_call_id>"`, the same on every
181
+ attempt), `attempt`, `events`, and `heartbeat`. Run the real tool once and
182
+ return `ToolExecutionResult(output)`. Tool calls of one model response run in
183
+ parallel Steps, so this method may run concurrently with itself.
184
+
185
+ Raise `ToolExecutionError(message)` for a failure the model should see; the
186
+ session records `failed` with that message and does not retry. Any other
187
+ exception is a Step failure. `read` and `idempotent_write` calls retry up to
188
+ three attempts, and then `RecordToolFailure` records `failed` for a read and
189
+ `outcome_unknown` for a write, because the write may have taken effect.
190
+ Single-attempt calls do not retry; `RecordToolOutcomeUnknown` records
191
+ `outcome_unknown`.
192
+
193
+ Before calling the runner, the tool Step writes `tool_call_started` and awaits
194
+ a heartbeat. Dex can redeliver a task to another Worker at the same attempt
195
+ when the first Worker disconnects before Dex receives any output, so this
196
+ output narrows that window before the tool runs. Awaiting the heartbeat only
197
+ queues the frame on the Worker; it does not wait for Dex to receive it.
198
+
199
+ ## Effects and policies
200
+
201
+ | Effect | Step | Retry | Crash mid-call | Default approval |
202
+ | --- | --- | --- | --- | --- |
203
+ | `read` | `CallTool` | Up to 3 attempts; then `failed` | Runs again | No |
204
+ | `idempotent_write` | `CallTool` | Up to 3 attempts, key `<flowId>/<turnId>/<toolCallId>`; then `outcome_unknown` | Runs again with the same key | No |
205
+ | `non_idempotent_write` | `CallSingleAttemptTool` | One attempt; then `outcome_unknown` | Outcome unknown | Yes |
206
+ | `unclassified` | `CallSingleAttemptTool` | One attempt; then `outcome_unknown` | Outcome unknown | Yes |
207
+
208
+ `ToolPolicy(effect, requires_approval=None)` overrides the defaults per tool
209
+ name; `None` uses the effect's default approval, which `is_approval_required`
210
+ reports. `AgentSessionOptions` also sets `default_tool_effect` (default
211
+ `unclassified`), the `AgentEvents` Stream capacity (default 10 MiB), and an
212
+ optional `interrupt_deadline`. A tool whose policy requires approval runs only
213
+ after `AwaitToolApproval` approves it.
214
+
215
+ ## Flow shape
216
+
217
+ ```text
218
+ StartAgentSession -> AwaitUserMessage -> RunModel
219
+ RunModel -> TurnCompleted -> AwaitUserMessage
220
+ RunModel -> ToolCallsRequested -> go_to_many(
221
+ AwaitToolApproval(id) -> CallTool(id) or CallSingleAttemptTool(id) per call needing approval
222
+ CallTool(id) or CallSingleAttemptTool(id) per other call
223
+ ResumeTurn(expected_result_count))
224
+ ResumeTurn -> RunModel
225
+ ```
226
+
227
+ | Step (input) | What it does | Next |
228
+ | --- | --- | --- |
229
+ | `StartAgentSession` (`AgentSessionStartInput`) | Start Step. Initializes state, usage, and interrupts. | `RunModel` with a non-blank `initial_message`, else `AwaitUserMessage` |
230
+ | `AwaitUserMessage` (none) | Waits for `QueuedUserMessages.for_one()`, stores the user message, starts the turn. | `RunModel` |
231
+ | `RunModel` (none) | Calls `run_model_step`. 15 min timeout, 2 min heartbeat timeout, 3 attempts in 30 min, failure route `RecordTurnFailure`. On `ToolCallsRequested`, stores the run state, one `AgentToolCalls` record per call, and the interrupts. | `AwaitUserMessage`, or `go_to_many` with one Step per tool call plus `ResumeTurn` |
232
+ | `AwaitToolApproval` (tool call ID) | Waits for `InterruptResolutions.for_one(id)`, plus a Timer at the deadline, rounded up to whole seconds, while the interrupt is pending. Approved: marks the record `approved`. Rejected or expired: records `rejected` and publishes `ToolCallResults`. A Timer that fires before the deadline waits again. | `CallTool` or `CallSingleAttemptTool`, or ends |
233
+ | `CallTool` (tool call ID) | Runs one `read` or `idempotent_write` call. 3 attempts, failure route `RecordToolFailure`. Records `succeeded`, or `failed` for `ToolExecutionError`, and publishes `ToolCallResults`. | Ends |
234
+ | `CallSingleAttemptTool` (tool call ID) | Runs one `non_idempotent_write` or `unclassified` call. 1 attempt, failure route `RecordToolOutcomeUnknown`. | Ends |
235
+ | `RecordToolFailure` (tool call ID) | Records `failed` for a read and `outcome_unknown` for a write, with the recovery detail in `error`, and publishes `ToolCallResults`. | Ends |
236
+ | `RecordToolOutcomeUnknown` (tool call ID) | Records `outcome_unknown` with the recovery detail in `error`, and publishes `ToolCallResults`. | Ends |
237
+ | `ResumeTurn` (expected result count) | Waits for `ToolCallResults.for_n(count)`. | `RunModel` |
238
+ | `RecordTurnFailure` (none) | Records `last_turn_error`. When the turn has final tool call records, appends one turn-failure note; otherwise appends nothing. Clears the turn's records and run state. | `AwaitUserMessage` |
239
+
240
+ Every Step sets `wait_for` and `execute` durability to SYNC explicitly, so a
241
+ `FlowConfig(step_durability=ASYNC)` never replays a Step result. Each tool
242
+ call Step and its failure route receive the tool call ID as input, so parallel
243
+ Steps never share state. Every tool call publishes exactly one `ToolCallResults`
244
+ message, when its record becomes final, and a tool Step whose record is already
245
+ final ends without running or publishing. `ResumeTurn` goes back to waiting if
246
+ a consumed result left a record of the turn unfinished. `AwaitToolApproval`
247
+ and the tool Steps load only their own `AgentToolCalls` instance, through
248
+ per-movement `StepOptions`.
249
+
250
+ Persistence, shared by every agent Flow type and exported from `dex_agents`:
251
+
252
+ | Name | Kind | Value |
253
+ | --- | --- | --- |
254
+ | `AgentState` | Attribute `AGENT_STATE` | `AgentState` |
255
+ | `AgentMessages` | AttributeMap `AGENT_MESSAGES`, key `message_sequence_key(n)` (12-digit zero-padded) | `AgentMessage` |
256
+ | `FrameworkRunState` | Attribute `FRAMEWORK_RUN_STATE` | string, set only while a turn waits for tool calls |
257
+ | `AgentToolCalls` | AttributeMap `AGENT_TOOL_CALLS`, key = tool call ID | `AgentToolCall`, deleted when the turn ends |
258
+ | `PendingInterrupts` | Attribute `PENDING_INTERRUPTS` | `list[AgentInterrupt]` |
259
+ | `AgentUsage` | Attribute `AGENT_USAGE` | `AgentUsage` |
260
+ | `QueuedUserMessages` | Channel `QUEUED_USER_MESSAGES` | `AgentUserMessage` |
261
+ | `InterruptResolutions` | ChannelMap `INTERRUPT_RESOLUTIONS`, key = interrupt ID | `AgentInterruptResolution` |
262
+ | `ToolCallResults` | Channel `TOOL_CALL_RESULTS`, internal | `ToolCallCompleted` |
263
+ | `AgentEvents` | Stream `flow.agent_events`, one per Flow type | `AgentEvent` |
264
+
265
+ `AgentState.status` is `waiting_for_user_message`, `running_model`, or
266
+ `running_tools`.
267
+
268
+ RPCs:
269
+
270
+ | RPC | Input | Output | Notes |
271
+ | --- | --- | --- | --- |
272
+ | `send_user_message` | `AgentUserMessage` | `bool` | Transactional; `False` for blank text. |
273
+ | `resolve_interrupt` | `ResolveInterruptRequest` | `bool` | Locks `PendingInterrupts`; `False` when not pending or past its deadline; removes the interrupt and publishes the answer in one commit. A concurrent Step can raise `RpcLockConflictError`; `AgentSessionClient` retries it for 5 seconds. |
274
+ | `get_agent_snapshot` | none | `AgentSnapshot` | State, last 200 messages, pending interrupts, the active turn's tool calls, usage, queued message count. Serves retained closed sessions. |
275
+ | `list_agent_messages` | `ListAgentMessagesRequest` | `AgentMessagesPage` | Oldest first; limit clamped to 1..200. |
276
+
277
+ Events on `AgentEvents` (`AgentEventType`): `turn_started` `{"sequence"}`,
278
+ `turn_completed` `{"message_count"}`, `turn_failed` `{"error"}`, `text_delta`
279
+ and `reasoning_delta` `{"text"}`, `tool_call_started` `{"tool_call_id",
280
+ "tool_name"}`, `tool_call_finished` `{"tool_call_id", "tool_name", "status"}`
281
+ (once per tool call, including rejections), `tool_call_deferred`
282
+ `{"tool_call_id", "tool_name", "effect", "requires_approval"}`,
283
+ `interrupt_raised` `{"interrupt_id", "tool_call_id", "tool_name", "deadline"}`,
284
+ `interrupt_resolved` `{"interrupt_id", "approved", "rejection_message"}`, and
285
+ `usage_recorded` `{"recorded", "session"}`.
286
+
287
+ Every event carries `turn_id`, `step_execution_id` (shared by all attempts of
288
+ one Step execution), and the Step `attempt`. A UI groups live text by
289
+ `(turn_id, step_execution_id, attempt)`: within one `step_execution_id` it
290
+ keeps only the highest `attempt` seen and drops the partial text of lower
291
+ attempts. Different `step_execution_id` values of a turn are separate model
292
+ call and tool call Steps, and each keeps its text. After `turn_completed` or
293
+ `turn_failed`, replace the turn's live text with the stored messages. Streams
294
+ are best effort; rebuild from `get_agent_snapshot`.
295
+
296
+ ## Testing an adapter
297
+
298
+ `dex_agents.testing` runs integration tests against a private `dexcli dev
299
+ --engine zd` engine. It reads `DEXCLI` and expects `dex-server-zd` next to it
300
+ (or `DEX_SERVER_ZD_BINARY`). The Worker runs in a child process in its own
301
+ process group, so a test can SIGKILL it at an exact moment.
302
+
303
+ ```python
304
+ # tests/my_worker.py: the Worker child.
305
+ from dex_agents.testing import run_agent_worker
306
+ from tests.my_agent import build_flow
307
+
308
+ if __name__ == "__main__":
309
+ run_agent_worker([build_flow()])
310
+ ```
311
+
312
+ ```python
313
+ # tests/test_approvals.py: the test process builds the same Flow for its Client.
314
+ from pathlib import Path
315
+ from dex_agents.testing import EXECUTE_COMPLETED_EVENT, AgentTestStack, wait_for_agent_snapshot
316
+ from tests.my_agent import build_flow
317
+
318
+ PACKAGE_DIR = Path(__file__).resolve().parents[1]
319
+
320
+ async def test_write_survives_a_worker_kill(tmp_path: Path) -> None:
321
+ flow = build_flow()
322
+ async with AgentTestStack(tmp_path, [flow], "tests.my_worker",
323
+ worker_cwd=PACKAGE_DIR,
324
+ worker_env={"MY_STATE_DIR": str(tmp_path)}) as stack:
325
+ sessions = stack.sessions(flow)
326
+ worker = await stack.start_worker()
327
+ await sessions.start_session("session-1", "refund order 7")
328
+ interrupt = await wait_for_agent_snapshot(
329
+ sessions, "session-1",
330
+ lambda snapshot: next(iter(snapshot.pending_interrupts), None),
331
+ description="a pending approval")
332
+ worker.kill() # SIGKILL while the session waits
333
+ await stack.start_worker() # replacement Worker
334
+ assert await sessions.resolve_interrupt(
335
+ "session-1", interrupt.interrupt_id, approved=True)
336
+ history = await stack.read_step_history("session-1")
337
+ executed = [entry.step_type for entry in history
338
+ if entry.event_type == EXECUTE_COMPLETED_EVENT]
339
+ ```
340
+
341
+ Run tests with `pytest-asyncio` in auto mode, as `pyproject.toml` here does.
342
+
343
+ Inside the Worker child, a tool marks a `FileGate(state_dir, name)` and awaits
344
+ `wait_for_release()`; the test awaits `wait_until_reached()` and kills the
345
+ Worker at that exact point. Two gates reached at once prove that two tool
346
+ Steps run in parallel. `InvocationLog(path)` counts real tool and model calls
347
+ across Worker processes. `read_step_history(server_address, flow_id)` lists
348
+ completed Steps (`StepHistoryEntry` with `event_type`, `step_type`,
349
+ `step_execution_id`, `final_attempt`) through `dexcli flow history`.
350
+ `wait_until(description, probe)` polls with a deadline instead of sleeping.
351
+ The core's own tests in `tests/` use a scripted runner and show every pattern.
352
+
353
+ Each package's `ci.sh` installs locked dependencies, runs lint and type
354
+ checks, and runs the integration tests with `DEXCLI` set. `Agents CI`
355
+ discovers every `agents/*/*/ci.sh`.
356
+
357
+ ## Design decisions
358
+
359
+ The plan records each of these decisions too.
360
+
361
+ - Step mode: one `RunModel` Step per model call and one Step per tool call,
362
+ READ included. No framework loop runs several model calls in one Step.
363
+ - Tool call Steps and their failure routes take the tool call ID as input.
364
+ There is no shared "current tool call" in `AgentState`.
365
+ - `RecordToolFailure` records `failed` for a read and `outcome_unknown` for a
366
+ write: it is reached only through crashes, timeouts, or exceptions other
367
+ than `ToolExecutionError`, so a write may have taken effect.
368
+ - `AgentToolCall.deferral_order` keeps model order for display and for the
369
+ turn-failure note; AttributeMap keys alone do not keep order.
370
+ - Nothing from a turn is stored until it completes. `TurnCompleted` carries all
371
+ of the turn's messages; `ToolCallsRequested` keeps them in the framework run
372
+ state.
373
+ - A failed turn that ran tools leaves a note message instead of appending
374
+ nothing, so its writes are not repeated by the next turn.
375
+ - Every Step sets SYNC durability explicitly.
376
+ - Message sequences start at 1. A blank `initial_message` starts no turn.
377
+ `last_turn_error` is cleared when a later turn completes.
378
+ - `resolve_interrupt` drops `rejection_message` on approval. When it resolves
379
+ an interrupt just as its deadline Timer fires, `AwaitToolApproval` waits
380
+ again and applies the answer.
381
+ - `AgentSnapshot.state` is `None` until `StartAgentSession` commits.
382
+ - Status, role, effect, and record status values are `StrEnum` types in Python;
383
+ the wire carries the plain strings.
384
+
385
+ ## Limits
386
+
387
+ - `RunModel` and `get_agent_snapshot` load the whole `AgentMessages` map.
388
+ History is never compacted, so very long sessions load more on every call.
389
+ - Each model call and tool call adds a Step round trip.
390
+ - A running turn cannot be steered or cancelled; new user messages queue until
391
+ it ends.
392
+ - Interrupt deadlines use the Worker clock.
393
+ - One `text_delta` call writes one Stream message; batch very small chunks.
394
+ - Tool call IDs that are empty or contain `/` fail the turn.
395
+ - A tool Step's first output narrows Dex's redelivery window but does not
396
+ close it. The awaited heartbeat only queues the frame. If the Worker dies
397
+ before the frame leaves it, or after it left but before Dex received it, Dex
398
+ can redeliver the same attempt and a single-attempt tool can run twice.
399
+ - A tool the framework cannot defer runs inside `RunModel` and repeats on a
400
+ `RunModel` retry.
401
+ - Whether turn records cleared at turn end still count against the Server's
402
+ `limits.maxFlowStateBytes` run budget is an open question in the parent
403
+ design.