The Five Acts of an AI Conversation Lifecycle: Why Architecture Matters

01 | A Conversation Is Not a Single HTTP Request

The author opens with a hospital outpatient analogy to map the five acts of a conversation lifecycle:

Registration → Act 1 · Host Submission: Which department, which ticket

Triage checks ID card → Act 2 · Main Platform to Front Gateway: Who you are — not what you claim

Guide takes you to the exam room → Act 3 · Front Gateway Three-Step: Eligibility, assigned room, doctor present

Doctor examines, orders tests → Act 4 · Runtime Turn: The real consultation, may loop multiple times

Write medical record and archive → Act 5 · Return Display & Persist: Under whose name this visit is filed

The analogy explains three steps often mistaken as "pass-through" but that must not be omitted:

Identity is not self-reported. Triage checks an ID card, not your verbal claim. Corresponds to Act 2's internal identity reverse-lookup; if you trust the request body's user ID, audit goes blind on incident day.

Guide takes you to the wrong department, everything after is wasted. Corresponds to Act 3's container routing: wrong shape means different toolset and permissions; user feels "this agent changed personality."

Saying "I'm not watching" doesn't stop the tests. Corresponds to the stop button needing to hit the runtime's cancellation semantics; UI-only stop leaves the doctor still writing orders.

The real acceptance criterion for "can chat" is a cross-layer lifecycle : who opened the session, which container, which turn, who handles stop, and under what identity history is persisted.

Two Common Failure Scenes

Scene A: Web works, CLI fails

Surface Symptom: "CLI broken"

Common Misdiagnosis: Reinstall client

Mechanism Truth: Different entry misses auth or external-capability layer before merge point

Scene B: Text streams but tools all fail

Surface Symptom: "Model can't use tools"

Common Misdiagnosis: Swap model

Mechanism Truth: Runtime didn't pull MCP/keys, or gateway routed to wrong container shape

One conversation lifetime = Entry Identity × Container Routing × Runtime Turn × Event Return Display × Audit Persist. Treat any link as "pass-through" and the lifecycle diagram is fake. The minimum viable loop is not "hits the model" but "hits the correct turn in the correct container, and can stop, and can record."

02 | Treating the Gateway as a Pure Reverse Proxy Breaks in Three Places

2.1 Entry Identity Never Becomes Internal Trusted Identity

Browser cookies, IM callbacks, CLI tokens, OpenAPI personal tokens all look like "someone logged in." The agent path needs a reverse-queryable caller identity entering the front gateway and runtime. Trusting the request body's self-reported user ID makes audit collectively blind on incident day.

2.2 Wrong Container Equals Wrong Life

The same agent may have usage-mode, dev-mode, collaboration/guest workspaces with different process configs. If the gateway forwards only by agent ID to "whatever address looks alive," it may enter the wrong shape: disk with IDE, headless usage disk, shared disk — toolsets and permission surfaces differ completely. User perception: "this agent changed person today."

2.3 Control Plane on Streaming Channel Treated as Decoration

Stop, resume, virtual session mapping look like auxiliary interfaces. They actually decide: whether the old turn keeps occupying the connection, whether the new question pours into the old bubble. Only forward stream, no control plane → conversation lifetime is incomplete: birth but no death or rebirth.

Architecture principles:

Steal "multiple entries converge to one Agent front gateway";

Reject "each entry connects directly to container";

Reject "stop only changes frontend button state."

Entry Pattern: Each entry direct to runtime — Steal: One less hop; Reject: Auth/routing fork, security and observability split

Entry Pattern: Only through traffic gateway — Steal: Simple site launch; Reject: Can't select container, can't do agent auth

Entry Pattern: Main Platform → Agent Front Gateway → Runtime — Steal: Identity and routing converge; Reject: Treat front gateway as pure pass-through and drop logic

Entry Pattern: OpenAPI / CLI bypass kernel — Steal: Automation fast; Reject: Grows a second conversation lifetime

03 | Five Acts, Many Faces for Entry, Only One Spine

Entries can have many faces; conversation lifetime allows only one spine — the segment from front gateway to runtime.

Dual-Layer Abstraction

Session Layer (What) — Responsibility: Who is chatting, which agent, which session/turn; Solves: Product semantics, quota, history ownership

Transport & Execution Layer (How) — Responsibility: Auth, select container, resolve address, stream, turn; Solves: Ground session semantics into the correct process

Many-faced entry + one spine + stoppable and recordable.

04 | Web and IM Lifetime, Act by Act

Act 1 · Host Submission

User sends a sentence on web or IM. Host (main platform conversation exit) does three things: session ID, agent ID, display projection. IM lacks full IDE, so display strategy diverges here — but still not inside container .

Act 2 · Main Platform to Front Gateway

Main platform BFF converts request to internal call: carries reverse-queryable identity , not letting runtime trust frontend's self-report. Audit must trace to person; identity material must converge before entering agent path.

Act 3 · Front Gateway Three-Step

Auth: internal token valid?

Select container: pick workspace by permission and shape (usage/dev/shared guest, etc.)

Resolve address: find living instance, then forward stream

"Process alive" and "should let you in" are two things, so auth failure and address resolution failure must alert separately.

Act 4 · Runtime Turn

Container's conversation process: pulls model-side keys and MCP config on demand, reuses CLI/SDK connections, starts this turn, drives tool loop, emits event stream. Cold-start connection is expensive, so "process up" ≠ "can respond in seconds."

Act 5 · Return Display & Persist

Events return to main platform: web renders directly; IM passes through another display layer (protocol, bytes, time window, queue — later dedicated article). Simultaneously writes audit and history by real caller identity . User sentences may carry secrets, so persistence pipeline must support desensitization — security article later.

Illustrative TypeScript checkpoint type:

// Illustrative · TypeScript
// Rules to keep: any checkpoint false → not "conversation link green"
type ChatLifetimeCheckpoints = {
  identityTrusted: boolean;   // Act 2
  containerSelected: boolean; // Act 3
  runtimeTurnReady: boolean;  // Act 4: connection hot, previous turn idle
  auditAttributed: boolean;   // Act 5: identity reverse-lookup before persist
};

function healthy(c: ChatLifetimeCheckpoints) {
  return Object.values(c).every(Boolean);
}

Illustrative Python:

# Illustrative · Python
def healthy(
    identity_trusted: bool,
    container_selected: bool,
    runtime_turn_ready: bool,
    audit_attributed: bool,
) -> bool:
    return all([identity_trusted, container_selected, runtime_turn_ready, audit_attributed])

Boundary: Increasing traffic gateway timeout won't fix "wrong container" — that's an Act 3 disease. Back to the clinic: no matter how long you wait in the lobby, the guide won't take you back to the right department.

05 | CLI and OpenAPI Share the Same Spine

Challenge: Automation entries take shortcuts straight to container, growing a second lifetime. Solution: CLI / OpenAPI / external protocol clients, after verifying at the external-capability layer, still enter the same Agent front gateway , then the same class of runtime. Platform needs unified permissions and observability, so "script-only bypass" is only allowed as temporary scaffolding, never as architecture.

Control Plane: Stop and Resume

If a conversation lifetime only has "send" without "stop," user pressing cancel only changes their mood. Old turn keeps occupying connection, so stop must hit runtime's cancellation semantics; resume and session mapping are gateway-runtime collaboration, not a frontend local flag. Stop button that only changes UI gives the conversation no death right — it becomes a zombie turn.

Boundary: OpenAPI may have its own quota and token shape, but must not have a second source of truth for container routing.

06 | Two Lifetimes, Walk Through Decision Points

Scene 1: Browser Normal Chat (Baseline)

Path: Host → Main Platform → Front Gateway Three-Step → Runtime → Model → Return Display → Persist.

A: Any act fails shows "model error."

B: Return per-act understandable failure (unauthorized / no available container / runtime busy / upstream inference fail).

Choose B. "Model error" four characters will drag a whole week of debugging into a ditch.

Scene 2: CLI Sends Text, Tools All 401

Path: CLI → External Capability → Front Gateway → Runtime; tools then go outbound to MCP / OpenAPI gateway.

A: Think conversation lifetime broke at model.

B: Conversation lifetime actually green to turn; break is at external capability identity (token invalid or unauthorized scope).

Choose B. Next article expands Tool/MCP. This article's acceptance point: you can point to "green to which act, red at which act."

Correlation ID Must Be Honest

Cross-layer debugging: don't assume every hop's request ID shares the same name and value. Gateway and runtime often have two correlation systems, so stitch with Agent + User + Time Window + Session ID . External training should teach "stitching," not pretend a single God-request-ID spans the universe.

07 | Selection: How to Choose Among Four Wiring Patterns

Three Layers of Value

⚡ Quantified Efficiency: Alerting by "act" collapses mean time to locate from "whole chain chaos" to "first lock down which act."

📥 Capability Push-Down: Frontline engineers can ask "stuck at container selection or stuck at turn" without memorizing deployment names first.

📚 Pattern Upgrade: From "connect SSE" to "manage conversation lifecycle" — leaves mount points for pooling, pre-warm, recycle, security audit.

Five-Dimension Selection Matrix

Dimension: Security Convergence — Entry Direct to Container: Low; Traffic Gateway Proxy Only: Low; Main Platform + Front Gateway + Runtime: High; Each Entry Own Lifetime: Low

Dimension: Multi-Entry Consistency — Entry Direct to Container: Low; Traffic Gateway Proxy Only: Medium; Main Platform + Front Gateway + Runtime: High; Each Entry Own Lifetime: Low

Dimension: Observability — Entry Direct to Container: Low; Traffic Gateway Proxy Only: Medium; Main Platform + Front Gateway + Runtime: High; Each Entry Own Lifetime: Split

Dimension: Engineering Cost — Entry Direct to Container: Low start; Traffic Gateway Proxy Only: Low; Main Platform + Front Gateway + Runtime: Medium; Each Entry Own Lifetime: Explodes later

Dimension: Recommendation — Entry Direct to Container: Forbidden as end state; Traffic Gateway Proxy Only: Only for site launch; Main Platform + Front Gateway + Runtime: Default ; Each Entry Own Lifetime: Reject

08 | Applicability, Four Pits, Change Grading

Applicable / Not Applicable

Applicable: Multi-entry, audit required, container selection needed agent platforms; Need stop/resume and history ownership

Not Applicable: Single-process local chat demo; One-off script calling model

Pit 1: Traffic Gateway Timeout as Universal Cure

Trigger: both site launch and chat launch carry "gateway" in name. Wrong cure: increase frontend traffic gateway timeout, hoping long tasks survive. Right cure: separate budgets for site launch vs chat launch; long tasks watch runtime and outbound tool timeouts.

Pit 2: Trust Client Self-Reported User

During debug, letting runtime read user ID from request body to write history is easiest. But once that hole opens, anyone can forge identity — and you discover it exactly when you need audit most. Correct way: internal identity reverse-lookup; audit only trusts reverse-lookup result, frontend payload ignored.

Pit 3: Stop Only in Frontend

Trigger: button is easy. Wrong cure: UI shows stopped, tools still writing disk. Right cure: stop must hit runtime cancellation semantics; acceptance checks whether side effects actually stopped. Back to clinic: not you sitting in the lobby, but the doctor actually putting down the pen.

Pit 4: Give CLI a Permanent Bypass

Automation wants speed, so someone lets CLI direct-connect container, bypassing auth and container selection. First months peaceful; when permission revocation or audit reports needed, discover this conversation branch never passed through audit pipeline, history empty. Speed via pre-warm, not bypass. Back to clinic: back door into exam room is fast, but the medical cabinet never records your visit.

L1 / L2 / L3 Change Grading

L1: Log by act, failure messages split by act

L2: Entry convergence refactor (remove bypasses)

L3: Container selection strategy / identity system changes

Summary

One conversation lifetime is a five-act play: Submit → Trusted Identity → Gateway Three-Step → Runtime Turn → Display & Persist.

Entries can have many faces, spine only one: Agent Front Gateway → Container Runtime.

Wrong container equals wrong life; auth passed ≠ entered correct shape.

Stop and resume are lifecycle control plane, not UI decoration.

Cross-layer debugging uses stitching, not faith in a single God request ID.

"Can chat" acceptance is "stoppable, recordable, correct turn," not "text appears."

Conversation link green is not hitting the model — it's hitting the correct turn in the correct container, and being able to die and be remembered.