Back to Blog
opencodemcpai workflowsupportbackendsdk

Building a Safe AI Support Investigation Platform

July 21, 2026
Nurhuda Joantama
Building a Safe AI Support Investigation Platform

Table of Contents

  • Why I built it
  • The shape of the system
  • How I came to this approach
  • Why the agent is read-only
  • The backend parts that matter
  • Lessons learned

The useful version of this project was not an unrestricted AI chatbot. It was a normal backend system with an AI investigator inside a controlled boundary.

I built an internal support investigation platform for a problem I kept seeing around technical support work.

A support question can sound simple: why did this record fail, why did the product return that response, or which configuration caused this behavior?

But answering it often requires developer-style investigation. Someone has to find the relevant code path, understand the business rule, inspect the right tables, compare production data with the implementation, and explain the result in a way support can use.

That was the workflow I wanted to improve.

Not by giving an AI agent broad production access.

Not by letting it edit code or run shell commands.

The goal was narrower: build a safe investigation assistant that can read the application codebase, query approved masked production data, and produce an evidence-based explanation for support engineers.

1 · Why I built it

Support engineers often sit between users and product internals.

They need enough technical context to understand what is happening, but they should not need unrestricted database access or constant developer interruption for every recurring case.

The repeated investigation flow usually looks like this:

  • understand the reported behavior
  • find the relevant module
  • trace the code path
  • inspect the right production records
  • decide whether the issue is data, configuration, implementation, or a limitation
  • explain the result clearly

That is a lot of context switching.

The product idea came from that gap. I wanted support engineers to create an investigation session, ask a question in natural language, and let the system perform the first technical pass.

If the case still needs a developer, the assistant should say that clearly and point to the area worth inspecting next.

2 · The shape of the system

The application behaves like a technical chat product.

A user creates a support session and submits a question. The backend stores the message, creates a queued investigation run, and a worker asks OpenCode to investigate using approved tools.

The final answer is stored back into PostgreSQL, so the support app remains the source of truth for users, sessions, messages, runs, and audit history.

The high-level shape is simple:

text
Browser
  -> NestJS API
  -> PostgreSQL
  -> Redis / BullMQ
  -> Worker
  -> OpenCode
  -> PHP monorepo + approved MCP tools

The frontend does not talk to OpenCode directly.

The support app owns authentication, authorization, sessions, messages, run state, polling updates, and sanitized errors. OpenCode owns the investigation runtime.

That separation matters. The AI agent can be useful without becoming the primary application database or the trusted security boundary.

The result is a shared investigation screen where support can ask a question, review the assistant answer, and keep the investigation history in one place.

AI Support Investigation application showing a support session with an assistant investigation result

3 · How I came to this approach

The idea became clearer when I started reading about the OpenCode SDK.

At first, I was not thinking about building a full product. I was mostly curious about what it would mean if a coding-agent runtime could be used from inside a normal backend application.

That changed the question for me.

Instead of asking, "Can I build another chat app?" I started asking, "What useful internal workflow could exist if my backend could create an OpenCode session, send an investigation prompt, and store the result?"

Support investigation felt like the right fit because OpenCode already works in the environment where the useful context lives: the codebase.

The SDK made the runtime feel programmable. The app could own the product layer, while OpenCode handled the code-reading and tool-using part.

That was also why I did not want to design this around a very vendor-specific assistant SDK.

I wanted something less locked to one model provider or one hosted assistant product. With OpenCode, the investigation layer can stay closer to the tools and provider setup I already use. It also fits my budget better because an OpenCode subscription around $10 per month is enough for this kind of internal experiment.

That combination made the project feel practical:

  • programmable from a backend worker
  • close to the target repository
  • compatible with MCP
  • less tied to one AI vendor workflow
  • affordable enough to keep running as a personal/internal tool

The useful insight was simple: OpenCode did not have to be only a terminal coding assistant.

It could become the investigation runtime inside a safer support product.

4 · Why the agent is read-only

The first rule of the system is simple: the AI investigator should not be able to change production or the codebase.

It can read files, search code, call approved MCP tools, and correlate implementation details with masked production data.

But it cannot:

  • edit files
  • run shell commands
  • execute arbitrary SQL
  • modify production data
  • deploy anything
  • bypass masking

That boundary is not just a prompt instruction.

One lesson I strongly believe after working with AI tools is this: a prompt is not a security policy.

The real security model has to live in tool permissions, credentials, network access, and infrastructure.

For this project, production data goes through MCP instead of direct database access. The MCP server exposes controlled read-only operations, applies PII masking, limits results, and only supports mapped tables and searchable fields.

The agent gets a narrow path:

text
read code
search code
ask controlled MCP tools for masked data
explain what was found

That is the difference between an AI chatbot with dangerous access and an investigation system with intentional boundaries.

5 · The backend parts that matter

The interesting part of this project was not only the chat UI.

The harder part was treating AI execution like normal backend work.

An investigation can take minutes. It can fail. OpenCode can be unavailable. MCP can return an error. Redis can have a temporary issue. A worker can crash after a run starts.

So the system needed the usual reliability pieces:

  • a queue
  • explicit run states
  • idempotent job processing
  • database transactions
  • row locking
  • heartbeats
  • stale-run recovery
  • sanitized error handling

Each user message creates one run. A session moves from idle to busy, and the run moves through queued, running, completed, or failed.

The backend also enforces one active run per session. The frontend disables the send button, but the backend cannot trust the UI alone. The database has to make the rule real.

That was one of the bigger lessons: AI agents still need boring distributed-system design.

The model does not remove queues, transactions, idempotency, or recovery logic.

6 · Lessons learned

Looking back, a few lessons stood out.

Read-only AI is already useful

An agent does not need write access to create value. Code search, controlled data lookup, and evidence-based explanation can already remove a lot of repetitive investigation work.

Prompts are not enough for safety

Instructions help shape behavior, but real boundaries need to be enforced through permissions, credentials, network access, and infrastructure.

The database should own product state

OpenCode is the investigation runtime. PostgreSQL owns users, sessions, messages, runs, and history. That separation makes the product easier to reason about.

Simplicity can be the right architecture

Polling was enough for the MVP because support users mainly need queued, running, completed, and failed states plus the final answer.

That choice is less fancy.

It made the system easier to operate.

7 · The main idea I would keep

The central idea behind this project is that AI support tooling should not be designed as an unrestricted chatbot with production access.

It should be designed as a controlled investigation system.

The AI is one component inside a larger architecture that defines who may ask questions, which data may be accessed, which tools may be used, which actions are impossible, how work is queued, how failures are recovered, and when a human developer should take over.

That is what made the project interesting to me.

The value does not come only from the model.

The value comes from combining the model with safe data access, explicit permissions, reliable backend workflow, and a product shape that matches how support and engineering teams actually collaborate.