SMOODEV-590: TS server honors per-agent config + conversation workflows

[brentrager]

Problem

Agents served by the TypeScript smooth-operator server ignored their per-agent config and always used one generic org-level customer-support persona. The server resolved behavior only from a single static systemPrompt set at construction — so every agent behaved identically, per-agent instructions were never applied, and conversation_workflow was unimplemented.

In the SmooAI monorepo agents table each agent has instructions (jsonb {prompt}) and conversation_workflow (jsonb); the TS server applied neither.

Approach

Ports the monorepo general-agent behavior (packages/backend/src/ai/graphs/general-agent/) into the TS server, mirroring the Rust agent-config-instructions-workflow design.

Config-delivery seam — AgentConfigResolver.resolve(agentId) (new src/agentConfig.ts), following the server's existing pluggable-seam pattern (AuthVerifier.resolve, AccessKnowledge.forAccess). Resolution is server-side because the create_conversation_session payload carries only an agentId (per spec/actions/create-conversation-session.schema.json). The reference StaticAgentConfigResolver is in-memory; a real deployment plugs in one backed by the agents table. An un-configured agent (no resolver, or resolver returns/throws) falls back to the server/org default prompt + full tool set — behavior unchanged.

Per-agent instructions — assembleSystemPrompt(base, config, currentStepId) makes the agent's own instructions the primary persona body, keeps the base org rules, and folds in optional greeting / personality. tool_config filters the server's tool set to an allow-list.

Conversation workflow (new src/workflow.ts) — the current step's intent + criteria render into the system prompt (renderWorkflowPromptSection); after each turn a cheap, failure-tolerant judge LLM call (judgeStep) decides whether the criteria were met and advances the pointer (explicit next or array order). currentStepId is tracked on the session (SessionStore.setCurrentStep).

Tolerance — parseWorkflow / parseAgentConfig degrade malformed config to the default flow and never throw; a judge error (or unparseable verdict) stays on the current step. A broken workflow doesn't discard a valid instructions.prompt.

Verification

• pnpm test — 98 passing (41 pre-existing + 57 new across workflow.test.ts, agentConfig.test.ts, agent-config-turn.test.ts): parse tolerance + hostile input, step resolve/next/render/advance, all judge verdict paths (yes/no/maybe/unparseable/thrown/empty-reply), prompt assembly with/without instructions/workflow/greeting/personality, and end-to-end over a real WebSocket — per-agent isolation, instructions honored, workflow advancement across turns, malformed-config + throwing-resolver fallback.
• pnpm typecheck clean (src + tests).
• Changeset added (@smooai/smooth-operator-server minor).

Notes

• Mirrors the Rust PR on agent-config-instructions-workflow (the canonical reference). That branch was not yet on origin when this was built; the only surface to reconcile is the resolver interface — the workflow render/judge/step-tracking semantics follow the shared monorepo reference. Flagged for a re-check once the Rust branch lands.
• The judge adds one cheap model call per turn only when a workflow is configured, and runs inline before the terminal eventual_response (content tokens have already streamed) so the advanced currentStepId is persisted before any next turn — no race.

🤖 Generated with Claude Code

https://claude.ai/code/session_011va1JyN3rTsfd2xuNGALed

[changeset-bot]

🦋 Changeset detected

Latest commit: 9fd15a7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/smooth-operator-server	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR