FPT Software · Enterprise Conversational AI
When a chatbot becomes a system.
At FPT Software, I worked primarily on prompt design, AI graph-node logic and tools for an enterprise conversational assistant. It was a team product with backend, frontend, retrieval, safety and distributed-service layers — not a system I built alone.
Why architecture mattered
The model call was only one stage.
Useful enterprise answers require coherent context, retrieval and tool choice, state continuity, permissions, controlled execution and clear failure handling. A retrieval miss, malformed tool response or queue timeout is not interchangeable with a model hallucination.
I contributed to the model-facing workflow while collaborating inside a broader Azure OpenAI and application-service ecosystem. I can explain the interfaces and trade-offs without attributing every service implementation to myself.
System-level capabilities
Capabilities with boundaries.
Conversation and orchestration
Prompt and graph-node behavior, conversation context and multi-step model decisions.
Retrieval and tools
Knowledge retrieval and tool interactions as explicit capabilities with separate data authority.
Safety and failure handling
Guardrails, deterministic application contracts, recovery and error semantics around probabilistic generation.
Service integration
Python AI services interacting with team-owned product APIs, background workers and web interfaces.
Engineering lesson
Keep ownership of state and truth explicit.
As soon as an assistant can search, route, remember and call tools, reliability depends on much more than fluent generated text. Each boundary needs to communicate what was observed, what failed, and what is still unknown.
My strongest personal contribution here was the AI workflow layer. I do not claim sole authorship of the product, proprietary model development, or unverified user/throughput metrics.
Related work