Building a Production-Grade AI Agent for Real SaaS: Sijil's Architecture in Practice

What happens when an AI Agent stops just generating text and actually operates a running software system? One developer answered that question with Sijil, a classroom management platform he built. He connected 22 tools wired to a production backend to Sijil's "Academic Assistant Agent," enabling it to query student information, attendance, grades, assessments, and more. But more importantly, this Agent doesn't just return JSON or plain text — it directly generates interactive React interfaces.

From Chatbot to System Operator

Most AI Agent implementations stop at "connecting an LLM to a database" — the model reads data and spits out a text response. Sijil takes this a step further: generative UI becomes part of the Agent interaction itself, rather than treating the Agent as a standalone chat window.

This design's value becomes clear when handling ambiguous requests. When a user asks "What are Ahmed's grades?" and multiple students named Ahmed exist in the system, the Agent doesn't guess or return an arbitrary result. Instead, it generates a selection component prompting the user to identify which Ahmed they mean before proceeding. This "hand control back when ambiguous" mechanism prevents the classic LLM problem of confidently fabricating answers under uncertainty.

Generative UI refers to an LLM dynamically deciding at runtime which UI components to generate, rather than having developers hard-code frontend logic in advance. Driven by frameworks like Vercel AI SDK, this pattern has taken shape in recent years: models don't just return text — they can return structured component descriptions that the frontend framework renders as real interactive elements like buttons, forms, and lists. Compared to traditional chat interfaces, generative UI's advantage is that it directly materializes "intent to act" as interface, reducing the cognitive overhead of users translating between natural language and software operations. In Sijil's implementation, the Agent transforms the cognitive step of "disambiguating" into a clickable selection component — structurally handling LLM uncertainty at the UI layer rather than leaving users to interpret text output.

Safety Boundaries for Database Writes

The real challenge emerges with write operations. A bad read returns inaccurate information; a bad write to a production database is a completely different category of risk.

When a user issues a change instruction like "Update Ali's assessment score to 8," the Agent doesn't execute immediately. Instead, it generates a confirmation interface clearly showing the before-and-after state:

• Previous: 6 → New: 8

No database changes occur until the user explicitly clicks confirm. Only after confirmation does the backend execute the change and record both before and after states in an audit log. This "preview → confirm → execute → record" workflow is essentially transplanting mature safety practices from traditional software into the Agent's operation chain.

Audit logs are a persistent record-keeping mechanism in enterprise software that captures "who did what to which data, and when." Their core value serves three purposes: post-hoc tracing (reconstructing the operation chain when data anomalies occur), compliance documentation (financial and educational industries typically have regulatory requirements), and anomaly detection (identifying errors or malicious behavior through log patterns). When Agents are involved in database operations, audit logs become even more critical — because LLM operation paths lack the static auditability of traditional code, runtime operation records become the only reliable accountability mechanism. Recording both before and after states (rather than just logging "an operation was performed") is a more complete audit practice that directly supports data rollback and diff comparison.

Underlying Architecture and Tech Stack

The overall call chain can be summarized as:

User → Agent → Tools → Sijil API → Database

The UI is dynamically generated as a product of Agent interaction throughout this process, rather than existing as frontend logic independent of the Agent.

The engineering stack supporting this system is comprehensive, covering every layer a production-grade SaaS requires:

Core Capabilities

• 22 Agent tools covering both queries and writes
• React-based generative UI
• Change confirmation mechanism
• Audit logging

Technology Choices

• Backend: NestJS
• Frontend: Next.js
• Database: MongoDB Atlas
• Deployment: Cloud Run + Docker + CI/CD
• Storage: Cloudflare R2 pre-signed uploads

Multi-tenancy and Security

• Multi-tenant isolation
• Rate limiting and token quotas

The inclusion of multi-tenant isolation and rate limiting signals that the author designed this as a real product for real users from the start — not a toy demo. When connecting an Agent to a production environment, quotas and isolation are the foundational defenses against abuse and data leakage.

Multi-tenant isolation is a foundational security requirement in SaaS architecture, ensuring that when a single system serves multiple independent customers (tenants), each tenant's data and operations remain invisible and isolated from the others. Implementation typically falls into three levels: database-level isolation (separate database instances per tenant), schema-level isolation (shared database but separate schemas), and row-level isolation (shared tables with tenant identifiers enforced at the query layer). In AI Agent scenarios, multi-tenant isolation faces an additional challenge: LLM-generated tool call parameters could potentially bypass conventional business logic layers and reach the data layer directly. Therefore, tenant identity verification must be enforced inside the tool functions themselves (not just at the UI layer) — otherwise a cleverly crafted prompt could lead the Agent to read or write across tenant boundaries. Rate limiting and token quotas protect against a single tenant over-consuming inference resources and degrading service quality for others.

The Questions Worth Thinking About

The author openly acknowledges that the most interesting problem isn't "how to give an LLM access to a database" — that's not technically hard. The real challenge is:

How do you let an Agent perform useful operations while maintaining the safety boundaries that ordinary software has always had?

This is a question that nearly every AI Agent deployment must confront. Traditional software's permission controls, operation confirmations, transaction rollbacks, and log traceability are all mature paradigms refined over many years. The introduction of Agents disrupts this established determinism — LLM outputs are inherently uncertain, and how to preserve safety guarantees without sacrificing the Agent's flexibility remains an open engineering problem.

The author also notes that he's still exploring "where the boundaries should be drawn," and has openly posed three specific questions to the community: How should tool permissions be managed? How should operation confirmation be designed? How should data changes be controlled?

Implications for Agent Developers

The reference value of Sijil as a case study isn't in what cutting-edge model it uses — it's in the pragmatic Agent deployment paradigm it demonstrates:

Treat the Agent as a system operator rather than a passive observer, while using generative UI, change confirmation, and audit logs to wrap an uncertain LLM inside a deterministic safety framework. For any team that wants their Agent to actually touch production data, the principle is straightforward: read operations can be open, write operations must have gates. That simple principle is worth borrowing.

As Agent capabilities grow, "how much authority to grant it, and how to provide a safety net" will become more important questions than "whether it can do something at all." Sijil's implementation offers a concrete starting point worth referencing.