AI Agents
Rashid Shaikh, CTO & Co-founder @ Coach Sensai
Jun 13, 2025
When we first set out to build Sensai, our AI-powered Agile Coach, the plan was straightforward: create a smart assistant that could handle daily standups and retrospectives inside Slack or Teams. Initially, we built our prototype using JavaScript/TypeScript—the stack we were most familiar with. But we quickly hit a wall.
The JS/TS Wall: Ecosystem Maturity Matters
While TypeScript offered us fast iteration, better tooling, and a familiar playground, it lacked depth in the AI ecosystem. Open-source LLM libraries were patchy, support for memory and agents was immature, and most of the LangChain/agentic experimentation leaned heavily into Python. We realized we were fighting the tooling more than building features. That’s when we made the leap.
“Choosing the right stack isn’t about what you know—it’s about where the ecosystem is heading. For LLM-based workflows, Python is already miles ahead.”
Switching to Python: A Better Fit for LLM Engineering
The transition to Python opened new doors. LangChain and the broader AI toolchain—vector stores, tracing, evaluation, prompt orchestration—all felt more production-ready. More importantly, it allowed us to experiment with LangGraph, which turned out to be the catalyst for a major architectural shift in Sensai.
Enter LangGraph: From Single Agent to Multi-Agent Architecture
We started small: one ReACT-style agent that could perform Scrum ceremonies. But as use cases expanded—daily standups, retrospectives, planning, ticket grooming, meeting summaries—we needed more specialization, memory control, and concurrency. LangGraph helped us break out of the monolith.
The Good
Composable Graphs: LangGraph’s graph-based abstraction let us model complex workflows elegantly.
State Control: Ability to pass and mutate state between nodes gave us clean separation of concerns.
Concurrency Support: Parallel branches let us invoke multiple agents simultaneously.
“We saw latency improvements of 40% in multi-agent flows by using LangGraph’s parallel execution branches.”
The Bad
Docs Were Sparse: At the time, LangGraph was early-stage. Documentation lagged behind capabilities.
Debugging State Was Hard: Without proper observability, tracing misfires was slow and painful.
The Ugly
Custom Serialization Edge Cases: Integrating with existing LangChain tools sometimes required kludgy workarounds.
Lack of Versioning: Early LangGraph didn’t support graph versions cleanly—made CI/CD tricky.
LangGraph in Production
Once we moved to production workloads, new learnings surfaced.
The Good
RemoteGraph Support: Huge win. We could deploy our LangGraphs independently and reference them via graph_id. This gave us modularity and CI-friendly deployments.
Graph Assistants: These became our way to configure different graph versions for different use cases (e.g., Standup Assistant v1 vs. Retrospective Assistant v2).
The Bad
Timeout Management: Certain multi-step workflows would hit execution time limits under load.
Error Handling: Try/catch-style flow inside graphs wasn’t intuitive at first.
The Ugly
Limited Persistence Hooks: We had to build custom caching + memory restoration when resuming threads.
“Some of our retrospectives crossed the 20k token mark with summaries, action items, and sentiment scores across multiple threads. LangGraph handled it—but not without sweat.”
Other Tools and Services offered by Langchain
LangGraph Studio: Game Changer
LangGraph Studio was a revelation. Finally, we could visualize our graphs, inspect state transitions, and track user threads. Debugging and collaborating became 10x easier. Especially in multi-agent graphs, seeing how state moved through each node helped squash subtle logic bugs.
“Before Studio, we debugged with print(). Now we spot bugs in 2 minutes that used to take 2 hours.”
LangSmith: Observability Nirvana
LangSmith helped us trace individual runs, monitor latency, and compare model responses across agents. When we added OpenTelemetry support, we were able to integrate it with our broader observability stack. Now we had not just model logs, but a full view of end-to-end system behavior.
The Current State: Modular, Multi-Agent, and Maintainable
Today, Sensai’s architecture is a web of Graph Assistants—each versioned, observable, and focused on a specific ceremony. LangGraph lets us invoke them dynamically via RemoteGraph, while LangSmith ensures every step is tracked and debuggable.
We process over 200 user prompts/day. (Including internal usages).
Our average end-to-end latency for standup agents is under 12 seconds. There is room for improvement.
We’ve reduced hallucinations by optimizing the context of the prompt. The next goal is to use eval loops to annotate and improve further.
“The moment we moved to modular Graph Assistants, our velocity tripled. Adding a new workflow is now a one-day job—not one week.”
What’s Next?
Dynamic Graph Generation: Based on user needs, we aim to assemble graphs on-the-fly.
LLM Cost Optimization: Using traces to benchmark token usage across agents.
Team-Level Memory: Beyond users—we’re building team-wide persistent context.
In Retrospect
LangGraph wasn't just a tooling choice—it reshaped our thinking. What began as a single smart agent solving a scrum master duty evolved into Coach Sensai, a modular system of a collaborating agile and delivery coach, all thanks to LangGraph's composability, state management and production-readiness.
“It took us four pivots to get here. But once we layered LangGraph + LangSmith + Studio, it finally felt like building with Legos—not duct tape.”
If you’re building AI agents that need coordination, memory, and traceability—LangGraph is a worthy investment. Just be ready for the good, the bad, and the very cool.
— Rashid Shaikh, CTO & Co-founder @ Coach Sensai