Supported execution bounds for delegated tasks

[gabrianoo]

We want to use T3 as the sole coordinator for bounded engineering tasks, with Claude implementing and Codex independently reviewing. Before unattended execution, the coordinator must be able to require limits that the execution layer enforces independently of the coordinator's conversation. We are seeking maintainer guidance and approval of the smallest supported direction before implementation.

Observed behavior

On installed v0.1.7, delegate_task.timeoutMs limits waiting, not child lifetime. Linux AgentScope already provides useful systemd scope cleanup, aggregate memory protection and process-count protection. We confirmed aggregate limits active locally. These facilities should be reused, not replaced by an external orchestration loop.

We also checked upstream main at b90e554:

• packages/contracts/src/orchestratorMcp.ts:168–196 exposes no required task execution policy; timeoutMs explicitly does not cancel the child.
• apps/server/src/process/agentScope.ts:93, 100–102, 175–203, 345–347, 398–417 shows the stop timeout, Linux scope setup and fallback, shared resource limits, and protection against killing shared scopes.
• docs/user/managed-policy.md:195–213 explains that the launching environment still reaches providers and permission-mode restrictions are not a sandbox.

Source links:

t3code/packages/contracts/src/orchestratorMcp.ts

Line 168 in b90e554

export const OrchestratorMcpDelegateTaskInput = Schema.Struct({

t3code/apps/server/src/process/agentScope.ts

Line 91 in b90e554

// systemd's default 90 s stop timeout would outlast our leftover-agent wait.

t3code/docs/user/managed-policy.md

Line 195 in b90e554

With `maxRuntimeMode` set, you own each provider's launch settings: binary path, launch arguments,

The missing workflow is admission conditioned on enforceable task bounds. Merely supplying a requested timeout, a coordinator-authored receipt, or a credential restriction in the prompt cannot establish that boundary. Shared provider processes also make killing a provider process an unsafe substitute for task-specific termination.

Proposed direction for discussion

Expose a supported, optional bounded-execution contract that reports available enforcement and refuses admission when a caller-required control is unavailable. Existing behavior could remain unchanged when bounded execution is not requested. A configured policy must not silently fall back to unbounded execution.

Start with one focused increment: enforced task lifetime and truthful terminal acknowledgement. It should bind the deadline to durable task identity, survive coordinator disconnection, reconcile server restart, and stop the task's descendants without affecting other threads sharing a provider. Unsupported provider/platform combinations should be refused explicitly.

Additional prerequisites for our unattended use case are credential confinement and enforceable resource/cost limits. We are not proposing to bundle all of those into the first PR or claim a deadline-only change completes the use case. We would appreciate guidance on whether existing provider-managed sandboxes or deployment isolation are the intended supported boundary, and how their effective guarantees should be exposed to admission. Any external sandbox would enforce execution only; T3 would remain the sole orchestration coordinator.

Acceptance criteria for the first increment

1. A task requiring a deadline is refused before launch if the selected provider/platform cannot enforce it.
2. Exceeding the deadline terminates that task and its descendants, leaves unrelated tasks running, and records a distinct terminal reason.
3. Coordinator disconnect does not disable the deadline. Restart either preserves enforcement or fails closed and reconciles the stopped task before replacement.
4. Cancellation requested and termination acknowledged are distinct states. A terminal result does not claim process-tree cleanup without evidence.
5. A lost launch response and retried request reconcile to one durable task rather than launch duplicates; existing idempotency mechanisms should be reused.
6. Focused tests use synthetic processes and isolated state. Real provider smoke tests are separately bounded. The installed live runtime and user credentials are not used as fault-injection targets.

Questions for maintainers

• Is bounded delegated-task lifetime an acceptable product direction, and is AgentScope plus provider-specific task termination the appropriate implementation boundary?
• How should shared Codex app-server sessions enforce a task deadline without terminating unrelated work?
• Is there an existing supported execution profile that already meets this requirement and should be documented instead?

Search performed: issue searches for delegated deadline and credential isolation found no results; a discussion search for deadline found an unrelated plugins proposal, and credential isolation found none. This is a bounded search, not proof that no related work exists.

No runtime patch or worker qualification is claimed. This proposal requests direction and scope approval in accordance with CONTRIBUTING.md, before opening a feature PR.

[MGRAFF2006]

I have a related use case for the enforcement described here: work allowances for ordinary personal threads as well as work explicitly shared with someone I know. I opened Connections #34261 for the sharing/discovery side, but would prefer to coordinate the execution limits here rather than invent a parallel mechanism.

For example: I start a task expecting a small amount of work, give it a runtime/token allowance in settings, and get a request to continue when that allowance is exhausted. The same owner-controlled allowance could constrain work started through a shared thread, project or machine. Children and retries should consume the same allowance, and the limit must not disappear when the viewing client disconnects.

Your distinction between wait timeout and actual execution lifetime is exactly the relevant boundary. Delayed token telemetry also means “interrupt when reported usage reaches this threshold” can overshoot; that must remain distinct from a native hard cap. A resource allowance bounds effort, not whether the agent is semantically staying in scope.

Would exposing the eventual bounded-execution contract through personal thread/project settings fit this direction, with unsupported guarantees stated before launch? I am asking about product scope, not proposing to add all budget types to the first deadline increment.

Prepared with gpt-6.1-sol through the Codex harness in T3 Code.