A practical look at building one AI desk that talks to your documents, your database, and the web. All at the same time.
The problem nobody talks about out loud
Someone on the operations team needs to know the incident response runbook for a specific system. They ask a colleague. That colleague isn't sure. They dig through Confluence, try a search, find something from 2022, hope it's still valid.
Meanwhile someone in data analytics wants yesterday's order count. They open a BI tool. Filter wrong. Give up. Ping the data team.
These are not technology failures. They're routing failures. The answers exist. Nobody knows where to look.
One Desk AI is a working attempt to fix that.
What it actually does
One question. One box. The system figures out where the answer is.
Ask it something about an internal process and it searches your uploaded documents using semantic (meaning-based) search. Ask it about data and it writes and runs a database query on your behalf. Ask it something general and it searches the web, reads the relevant pages, and gives you a summary.
You don't choose which mode. The system does.
The response comes back the same way every time: clean with any personal data removed and with a full trace of which agent ran, why it was chosen, and how long each step took.
The four agents behind the single answer
The system runs four specialized agents in sequence. Each one does exactly one job.
Knowledge Brain handles your internal documents. It uses vector search (think of it as search that understands meaning, not just keywords) over an OpenSearch index. If a question contains an organization name or mentions internal content, this agent runs.
SQL Agent handles data questions. It does not simply generate a query and run it. It generates the query, then has a second model verify it for safety before execution. This prevents the obvious disasters.
Research Agent handles everything else. It runs a Google search, reads the actual pages, and synthesizes a response. Not snippets. The full content.
Author Agent runs last on every response. It reformats the output for readability, strips any personally identifiable information, and is the only agent that writes to the user. One output point, always.
There is also a guardrail layer at the front. Before any agent runs, the input is checked for SQL injection attempts and similar attacks. Blocked inputs never reach the agents.
Why this matters for non-technical managers
The honest version: most AI tools companies buy are wrappers around a chat interface with one source of truth. Ask a question about a document, get an answer about the document. That's it.
This system connects three sources at once and decides between them per question. A new hire asking "what's our leave policy?" gets the HR document. A manager asking "how many leave requests were filed last quarter?" gets a live database query. No manual switching. No knowing in advance which system holds the answer.
The evaluation layer matters too. Every response is written to a database table: the original question, which agent handled it, the raw output, the final response, whether any PII was masked, and latency per stage. That's not for debugging. That's the audit trail compliance teams ask for and rarely get from AI tools.
Where it runs and what it costs to operate
The system deploys on AWS ECS Fargate which means there are no servers to manage. It starts a container when a request comes in and scales with demand. The AI model runs on AWS Bedrock (Claude 3.5 Sonnet) which means pay-per-use with no GPU procurement.
For a mid-sized company with moderate query volume the infrastructure cost is low. The bigger cost is the initial setup: getting documents into the search index, configuring which organization names the knowledge agent should recognize, and connecting the database.
Setup instructions are in the repository. The config that controls everything including which organizations the system knows about is a single YAML file. One edit, redeploy, done.
What this is not
It is not a replacement for a proper knowledge management system. If your internal documents are scattered, incomplete, or outdated, this system will surface scattered, incomplete, or outdated answers with confidence.
It does not handle ambiguous questions well. "How are we doing?" will confuse the routing layer. Specific questions get better answers.
It does not do anything about data quality in your database. If the data is wrong, the query results are wrong.
A note on the technical choices
The LangGraph version constraint is worth reading even if you never touch the code. The README documents which exact package versions work together and why upgrading them individually causes silent failures. That section alone is worth saving for anyone who has debugged a LangChain version mismatch at midnight.
The WebSocket implementation is also non-obvious. Long-running AI responses don't fit neatly into a standard HTTP request-response cycle. The system streams progress events back to the client so users see which agent is running while the answer is being assembled. The Angular integration contract is documented with working code.
Guardrails and PII masking are built to extend
This is a multi-agent system so the guardrail layer was designed as infrastructure rather than a fixed list of rules.
The input guardrail blocks SQL injection attempts before any agent runs. The Author Agent masks PII on every response regardless of which agent produced the answer. Both sit at fixed points in the graph so adding new checks means editing one file not hunting across four agents.
The config that controls routing also controls which patterns the guardrail flags. A team in a regulated industry can add domain-specific risk patterns in the same YAML that defines their organization names. No code change required for the common cases.
The masking rules follow the same pattern. New entity types can be added through config. The current defaults cover emails, phone numbers, and national ID formats for Indian regulatory context (aligned with DPDP Act requirements). Adding new formats is a config entry.
The design intent: guardrails in a multi-agent system should be easier to extend than a single-model wrapper because the insertion points are explicit and documented.
What's next
The current system handles text queries. The next logical step is audio: speak the question, get the answer read back. The architecture already supports it. Web search quality could also improve by adding domain filtering for trusted sources.
Read the full code
Everything described here is working code, not a demo or a mockup.
github.com/Manisoft55-lab/one-desk-ai
The README walks through local setup with Docker Compose to full ECS Fargate deployment. The test client lets you try all four agent paths with one command.
If you build something on top of it or run into a version issue the docs don't cover, open an issue.
Built at Manisoft Labs. Questions about the architecture or deployment: find me on LinkedIn.