feat: implement SmartChatAgent for real, grounded in the existing ChatManager - #7
Merged
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>
kowshikdev
added a commit
that referenced
this pull request
Jul 23, 2026
fix: land SmartChatAgent (PR #7 merged into the wrong base)
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.
Stacked on #6. Implements the conversational assistant behind
/assistant/start,/assistant/chat,/assistant/end— replaces the 501 guard from #6 with the real thing.Not built from nothing
orchestration/chat_workflow.py'sChatManageralready implements the real pipeline: multi-turn history, follow-up detection, intent classification with context, clarification prompts, routing through the super-graph, follow-up suggestions.agents/smart_chat.pyis a thin adapter over it, in the exact shaperoutes_ai.pyalready calls it in.Two real gaps found while wiring this up
ChatManager.process_messagecomputedconfidenceandreasoning_trace(both returned byprocess_user_request) and then discarded them before returning —routes_ai.py's response shape has fields for both. Threaded through.POST /assistant/chathardcodedconfidence: 0.8on the error path — claiming 80% confidence in a response that is, by definition, a failure. NowNone. The handler itself (catch, return "I encountered an issue" as a chat reply) is legitimate — a chat UI showing an inline error is honest degradation, unlike fabricating business data.Also fixed
SmartChatAgent(repo, use_llm=True)never accepteduser_emailanywhere in the original (never-ran) code, even though every constructing endpoint has it in the payload. Added it as a real parameter.use_llm=Falseis rejected withNotImplementedErrorrather than silently ignored — no call site passes it, and there's no non-LLM fallback for the underlying pipeline.Tests
The LLM gateway and the super-graph (which fans out to Redis-backed subgraphs for all six specialized agents) are stubbed at the two points
chat_workflow.pyitself calls them —EnhancedLiteLLMGatewayandprocess_user_request. That's the real dependency boundary; it letsChatManager's own logic run for real without needing a live LLM or Redis.The old
TestAssistantEndpointsFailClearly(asserting 501) is gone — replaced with route-registration checks plus real behavioral tests intest_smart_chat.py.Full suite: 59 pass, 2 skip.