Backend execution foundations — dispatch, orchestration and task results #153

Outcome

Nav develops the backend execution fundamentals needed for agentic work, partnering with Anshuk on Litestar/API admission, PostgreSQL state and transactions, lifecycle, basic dispatch/orchestration and one simple Graph request/result passage. Discord/Reach supplies the first practical scenario. Workflows, Agents and Context remain the direction; their deeper design follows the evidence from these basics.

Primary: Nav (@NavSrijan)
Partner: Anshuk (@geeked-anshuk666) — host-side execution, persistence and failure/recovery reasoning.
Shared outcome: #131. Current implementation: draft PRs #149 and #150; retain their separate scopes and review histories.

First result

• Trace one allowlisted message through caller/channel admission, conversation or workflow binding, supplied context, exact result audience and reply. Distinguish display name from identity/authority and identify where task/revision identity is retained. Trace the native Agent/Graph request separately and map the existing or missing handoff; implementing the whole connection is not a prerequisite for this foundation.
• Use Make the Reach operator's display name configurable and fix Podman hosts #149/Configurable model binding for Reach and an operator opt-in for Portal dispatch #150 as current review material: explain their changes, reproduce the relevant case on the selected revision/profile and complete required checks before asking for adoption. Their presence does not establish accepted architecture or a qualified merged baseline.
• Demonstrate one public project question and one refused/unrecognized caller, with actual observations and fixture/live boundaries stated.
• Co-design one pre-authorized PC task with Anshuk: operation/inputs, execution destination, result and disconnected/unknown outcomes. Identify missing receiver/private-data/result-disclosure work after the founder's topology decision; do not blindly repeat an uncertain operation.
• Explain the current context handoff and choose one small follow-on workflow/context experiment. Connect memory and identity questions to their existing owners; no general memory/identity implementation is required for this first result.
• Review the reusable path with Anshuk and share it with Chirayu/Kiran. Record the next bounded change rather than opening another parallel subsystem.

Backend depth for the first trace

Use the existing narrow path to explain request/service boundaries, the transaction and retained result, capability matching and observed availability, an admitted grant, execution and lease release/cleanup. Show where Graph waits or reports failure and where Orchestrator owns readiness changes; retry must follow the actual effect/recovery contract. Identify missing connections honestly rather than assuming Reach already uses the whole native path.

Partner with Anshuk's #152 task/result/human-feedback persistence example. Explain when the request, execution observation and human decision become durable and how a caller sees the retained result after interruption. Reproduce a useful case and a relevant refusal/unavailable/cleanup case. Complete generalized dispatch/orchestration is not a prerequisite for this small Graph passage.

Later direction — missing-capability inquiry

Keep the following as candidate questions through founder-led #40. Select the exact question and depth after the representative backend passage identifies a useful need. It is not another current implementation allocation; the foundation's small follow-on may simply repair or clarify the existing path.

• Choose one public/synthetic request where the bot cannot satisfy the requested capability. Trace the actual stopping point and distinguish absent capability/contract, unavailable or cold execution, and refused authority. Reuse/admit an existing capability where appropriate; not every failure requires new code.
• With the founder, frame one tiny source-bound inquiry: desired result, exact revision/evidence, missing contract, acceptance, non-goals and finite budget. Retain a candidate explanation plus a separately attributed challenge/review, or explicit insufficient evidence.
• Return an inert next-change request for the SDLC decision. Name any operator-mediated handoff; this probe does not require the complete Discord-to-Creation connection. A subsequent code-producing slice needs its own bounded workspace, verification and adoption decision through SDLC / Creation — one software request to a verified candidate #40.
• Discuss the flow with Anshuk and later explain/reproduce one step with Chirayu/Kiran through Enter — prepare the shared reproduction and acceptance journey #133. The shared learning covers workflow identity, agent role, bounded Context, capability dispatch, readiness/orchestration and what may leave the host; Context — scoped inputs and an enforced egress boundary #25/Future capability register — preserved outcomes and selection boundaries #62 retain anonymization and egress acceptance.

Scope

This is Nav's backend execution foundation toward agentic work, using Discord as its first scenario. Linux host discussion/reproduction with Anshuk supports the same main work; Atelier #162 remains a side quest. Include Context/privacy and result-audience questions in the existing handoff explanation; #25 and #62 own egress/anonymization, with memory/identity follow-ons selected narrowly.

This continues current Reach work, not a second display-name/model-binding/Podman project. Preserve the founder's #149 direction: temporary Nadir is accepted; later explicit operator binding derives the saved Primus name, with Primus fallback and the Discord-specific override retained. Preserve the founder's #150 direction: direct Reach API and per-Portal allow_dispatch remain developer/test-data experiments, off by default, and can send prompts/history as-is. They do not deliver the general privacy/egress/spend gates; #25 retains exact-destination/payload admission and required transformation for both paths. Keep the one review-ready implementation per pair limit; drafts may remain separately inspectable while their review order is agreed.

Working method

Understand the existing foundations and review any proposed shared-contract changes before multiplying implementations. Use coding agents for investigation, bounded prototypes, implementation and independent challenge. A small prototype can run alongside design and inform it; it must identify fixtures and assumptions. After the representative path and its reusable pattern are understood, build quickly within those boundaries.

The primary coordinates this result; the partner helps design, reviews the explanation and reproduces the example. Others may contribute or propose a different approach. The author reviews the full generated diff. Founder architecture/code approval and CONTRIBUTING remain in force. Bring one concise evidence packet: demo/trace, changed contracts, failure observations, checks and the next decision.

Checkpoint: the next shared planning/demo after the first reproduction. This is one bounded foundation result, not completion of the larger linked capabilities. Keep at most one review-ready implementation slice per pair awaiting the founder.