fix: land SmartChatAgent (PR #7 merged into the wrong base) - #8
Merged
Conversation
…tManager
The conversational assistant behind /assistant/start, /assistant/chat,
/assistant/end. `backend/routes_ai.py` did `from app.smart_chat import
SmartChatAgent` against a module that was never committed anywhere in this
repository -- there is no `app/` package at all. That missing import took the
entire FastAPI app down at boot (fixed with a 501 guard in the previous PR;
this PR replaces the guard with the real thing).
Not built from nothing. `orchestration/chat_workflow.py`'s ChatManager
already implements the real pipeline this needs: multi-turn history,
follow-up detection, intent classification with context, clarification
prompts, routing through the super-graph, follow-up suggestions.
agents/smart_chat.py is a thin adapter over it, in the exact shape
routes_ai.py already calls it in (`agent.context.session_id`,
`agent.chat_sync(message)` -> `{"content", "metadata": {...}}`).
Two real gaps found and fixed while wiring this up:
- ChatManager.process_message computed confidence and reasoning_trace (both
returned by process_user_request) and then discarded them before
returning -- routes_ai.py's response shape has fields for both. Threaded
through rather than left dropped.
- The exception handler in POST /assistant/chat hardcoded confidence: 0.8 on
the ERROR path -- claiming 80% confidence in a response that is, by
definition, a failure. Now None. (The handler itself -- catching an
exception and returning "I encountered an issue" as a chat reply -- is
legitimate: a chat UI showing an inline error is honest degradation, unlike
fabricating business data. What was wrong was the specific hardcoded number.)
Also fixed: SmartChatAgent(repo, use_llm=True) never accepted user_email
anywhere in the original (broken, never-ran) code, even though every
constructing endpoint has it in the payload. Added it as a real parameter --
threading it through is what makes the chat actually personalized to who's
asking, and there was no reason to keep discarding it now that this is a real
implementation, not a stub.
use_llm=False is rejected with NotImplementedError rather than silently
ignored: no call site anywhere passes it, and there is no non-LLM mode for
the underlying pipeline to fall back to.
## Tests
The LLM gateway and the super-graph (which itself fans out to Redis-backed
subgraphs for all six specialized agents) are stubbed at the two points
chat_workflow.py itself calls them -- EnhancedLiteLLMGateway and
process_user_request. That's the real dependency boundary of the code under
test; it lets ChatManager's own logic (turn history, follow-up detection,
clarification, response shaping) run for real without needing a live LLM or
live Redis for a full super-graph invocation.
test_app_boots.py's old TestAssistantEndpointsFailClearly (asserting 501) is
gone -- that behavior no longer exists on purpose. Replaced with
TestAssistantEndpointsAreRegistered (routes exist, don't 404) plus the real
behavioral tests in the new test_smart_chat.py.
18 new/changed tests pass. Full suite: 59 pass, 2 skip (Redis-required cases).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
feat: implement SmartChatAgent for real, grounded in the existing ChatManager
This was referenced Jul 23, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR #7 was stacked on
fix/graph-api-and-stabilize(PR #6). PR #6 merged intomainfirst; PR #7 then merged intofix/graph-api-and-stabilize— a branch, notmain— soagents/smart_chat.pyand the rest of the SmartChatAgent work never actually landed.Same class of mistake as earlier in this session with a different repo's stacked PRs. Confirmed directly:
git show origin/main:agents/smart_chat.pyfails; the file exists in the working tree but not onmain.No new changes — this is exactly what PR #7 already contained, brought over to the actual default branch. Closes #2, #4, #5 (the ones PR #6 referenced that didn't auto-close, likely because they weren't in the same PR body clause GitHub parsed as a closing keyword for a multi-issue list).