DEV Community: Jestony Silvano

How I Built an AI Assistant for My SaaS CRM with Scoped Agents

Jestony Silvano — Thu, 24 Sep 2026 12:27:18 +0000

How I Built an AI Assistant for My SaaS CRM with Scoped Agents

When I first started adding AI to my SaaS CRM, the obvious idea was simple:

Give the AI access to the CRM data and let users talk to it naturally.

But the more I worked on it, the more I realized that "an AI assistant for my CRM" isn't really one problem.

A CRM has different users, organizations, roles, private data, public documentation, and actions that can change data.

A personal assistant shouldn't have the same context as an organization assistant. A public product assistant definitely shouldn't have access to a customer's CRM records.

So instead of building one giant AI assistant, I designed uniThread's AI system around scoped agents.

The goal was simple:

Give each agent only the context, knowledge, and tools it actually needs.

This is how I built it.

The problem with one giant AI agent

Imagine having one AI agent with access to everything:

                    AI Agent
                       │
        ┌──────────────┼──────────────┐
        │              │              │
    User Data      CRM Data       Platform Docs
        │              │              │
        └──────────────┼──────────────┘
                       │
                    Tools
                       │
                   Database

At first, this looks convenient.

The model can answer more questions and perform more actions because it has access to more information.

But it creates a much bigger authorization problem.

What happens when a user asks:

"Show me the contacts in my organization."

That's different from:

"What is uniThread?"

And both are different from:

"Create a task for John tomorrow."

The AI needs to know not only what the user is asking, but also what the user is allowed to access and what the application is allowed to execute.

This is where I started separating the system into scoped agents.

What are scoped agents?

Instead of having one agent responsible for everything, I defined agents around different contexts.

The simplified architecture looks like this:

                         User
                           │
                           ▼
                     AI Request
                           │
                           ▼
                      Agent Scope
                           │
          ┌────────────────┼────────────────┐
          │                │                │
          ▼                ▼                ▼
   Personal Agent   Organization Agent   CRM Agent
          │                │                │
          ▼                ▼                ▼
   Personal Context   Org Context      Platform Context
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                     Available Tools
                           │
                           ▼
                      Authorization
                           │
                           ▼
                    Application / DB

The important part is that the agent isn't just a different system prompt.

The scope affects the context and capabilities available to the agent.

The three agent contexts

For uniThread, I currently separate the AI system into three main contexts.

1. Personal Assistant

The personal assistant operates around an individual user's context.

For example, this could eventually handle things such as:

Personal tasks
Personal notes
User-specific information
Personal workflows

The important part is that its context belongs to the user.

User
  │
  ▼
Profile
  │
  ▼
Personal Assistant
  │
  ▼
Personal Context

It shouldn't automatically gain access to an entire organization's CRM just because the user is logged in.

2. Organization Assistant

The organization assistant works within an organization's context.

A user's organization membership and role become important here.

For example:

User
  │
  ▼
Organization Membership
  │
  ├── Organization ID
  ├── Member ID
  └── Role
          │
          ▼
   Organization Assistant

The assistant can then work with organization-level CRM capabilities, subject to the same authorization rules as the rest of the application.

This is especially important in a multi-tenant SaaS application.

A user belonging to Organization A shouldn't be able to use the AI to retrieve information from Organization B.

The AI doesn't get to bypass the application's tenant boundaries just because the request is expressed in natural language.

3. CRM Assistant

The third agent is the public-facing CRM assistant for uniThread.

This one has a very different purpose.

It's designed to answer questions about the platform itself using documentation and other indexed knowledge.

For example:

"What does uniThread do?"

or:

"How does lead management work?"

This agent uses retrieval rather than accessing a customer's private CRM records.

The architecture is roughly:

User Question
      │
      ▼
   CRM Agent
      │
      ▼
 Retrieve Relevant Docs
      │
      ▼
    Context
      │
      ▼
     LLM
      │
      ▼
 Answer + Citations

This separation is important because knowledge about the product is not the same thing as access to customer data.

The context passed into the AI system

To keep the agent aware of its execution context, I use an agent context similar to:

type AgentContext = {
  profileId?: string;
  orgId?: string;
  memberId?: string;
  role?: "owner" | "manager" | "agent";
  accessToken?: string;
  isPublic: boolean;
};

Not every agent needs every field.

For example, a public CRM assistant doesn't need a customer's organization ID.

An organization assistant does.

A personal assistant may primarily care about the user's profile.

This gives the application a structured way to describe:

Who is making this request, what organization are they operating in, what role do they have, and what kind of AI interaction is this?

The architecture

I didn't want my controller to contain all of the AI logic.

The system is separated into several layers:

Controller
    │
    ▼
AIAgentService
    │
    ▼
Orchestrator
    │
    ▼
Model Router
    │
    ▼
Agent / Model Adapter
    │
    ▼
Tools
    │
    ▼
Authorization
    │
    ▼
Execution

Each layer has a different responsibility.

Controller

Receives the request and handles the API boundary.

AIAgentService

Handles the higher-level AI interaction.

Orchestrator

Coordinates the agent flow, context, model, tools, and execution.

Model Router

Allows the application to choose the appropriate model or provider without coupling the rest of the system directly to one model.

Agent / Model Adapter

Handles the model-specific implementation.

Tools

Expose controlled application capabilities to the model.

Authorization

Determines whether the requested operation is actually allowed.

Execution

Performs the approved operation against the application or database.

This separation became increasingly important as the AI functionality grew.

The most important distinction: AI is not authorization

One of the biggest things I learned while building this system is:

The LLM should never be the final authority on what a user is allowed to do.

A model can interpret intent.

It can decide that a user's request probably corresponds to create_task.

But it shouldn't decide whether the user is actually allowed to create that task.

The flow should look more like:

User Request
     │
     ▼
     LLM
     │
     │ "I want to call create_task"
     ▼
Tool Request
     │
     ▼
Authorization
     │
     ├── Not allowed → Reject
     │
     ▼
Validation
     │
     ▼
Confirmation if required
     │
     ▼
Execution

The model proposes an action.

The application decides whether that action can happen.

That distinction is critical.

Giving the agent tools

Instead of giving the model unrestricted access to my backend or database, I expose specific tools.

Some examples in my CRM assistant architecture include:

search_contacts
create_note
create_task

This gives the model a controlled interface.

For example, if the user says:

"Find John from Acme."

The model can determine that it needs the contact search capability.

If the user says:

"Create a follow-up task for John tomorrow."

The model can determine that create_task is relevant.

The model doesn't need to know how my PostgreSQL tables work.

It doesn't need raw database credentials.

It doesn't need unrestricted SQL access.

It only needs the capabilities that the application intentionally exposes.

Read operations vs mutations

Not every tool should be treated the same way.

There's an important difference between:

"Find my contact named John."

and:

"Create a task for John tomorrow."

The first is a read operation.

The second changes application state.

That means mutations need stronger controls.

A simplified flow can look like this:

Read:

User
 ↓
AI
 ↓
Tool
 ↓
Authorization
 ↓
Result

For a mutation:

User
 ↓
AI
 ↓
Tool Request
 ↓
Authorization
 ↓
Validation
 ↓
Confirmation
 ↓
Execution

The exact confirmation rules can vary by operation, but the underlying idea is the same:

Don't let a language model silently perform important state-changing actions just because it generated a tool call.

Scoped tools

The agent scope also affects which capabilities are available.

Conceptually, the system can look like:

Personal Agent
 ├── Personal Tasks
 └── Personal Notes

Organization Agent
 ├── Contacts
 ├── Tasks
 ├── Notes
 └── Other CRM Operations

Public CRM Agent
 └── Platform Documentation Search

This means the public CRM assistant doesn't suddenly get access to:

search_contacts
create_task
create_note

for a customer's private organization.

Its job is to answer questions about the platform, not operate someone's CRM.

That's a much smaller and more controlled problem.

Scoped agents are not a replacement for authorization

This is probably the most important security point in the architecture.

Having an agent called organization-assistant doesn't magically make it secure.

You still need authorization underneath it.

My application already has organization and role boundaries, and those boundaries need to continue applying when requests come from an AI agent.

The architecture therefore becomes layered:

AI Agent Scope
      │
      ▼
Application Authorization
      │
      ▼
Organization / Member Scope
      │
      ▼
Database Security
      │
      ▼
Data

The AI layer is another interface into the application.

It shouldn't become a shortcut around the application's existing security model.

How this connects to PostgreSQL RLS

This is also where my previous work on PostgreSQL Row Level Security became important.

The AI system sits above the database security layer.

For example:

User
 ↓
AI Agent
 ↓
Tool
 ↓
Application Authorization
 ↓
PostgreSQL
 ↓
RLS
 ↓
Tenant Data

The application can validate the request, while PostgreSQL RLS provides another boundary at the data layer.

This gives the system defense in depth.

If you're interested in the database side of this architecture, I wrote about it in my previous article:

How I Built Multi-Tenant Data Isolation for My SaaS CRM with PostgreSQL RLS

The two problems are closely related.

The first is:

How do I keep tenants from accessing each other's data?

The second is:

How do I let AI interact with that data without bypassing those boundaries?

RAG for the public CRM assistant

For the public CRM assistant, I also needed a way to answer questions about uniThread without relying entirely on the model's built-in knowledge.

That's where RAG comes in.

The basic flow is:

Documentation
     │
     ▼
Chunking
     │
     ▼
Embeddings
     │
     ▼
Vector Search
     │
     ▼
Relevant Context
     │
     ▼
LLM
     │
     ▼
Answer

Instead of asking the model to simply "know" how uniThread works, the application retrieves relevant documentation and provides that information as context.

This also gives me a better path toward citations and reduces the chance of the model inventing product information.

Most importantly, the RAG knowledge base is separate from private customer CRM data.

That's another example of why scope matters.

What happens when something goes wrong?

AI systems don't always behave exactly as expected.

A user might ask for something outside the agent's scope.

The model might choose an inappropriate tool.

A tool might receive invalid parameters.

The user might not have permission to perform the requested action.

The database operation might fail.

So I don't treat:

LLM → Database

as a valid architecture.

Instead, there are several boundaries:

LLM
 ↓
Tool Selection
 ↓
Input Validation
 ↓
Authorization
 ↓
Confirmation
 ↓
Business Logic
 ↓
Database

Each layer gets an opportunity to reject an invalid operation.

This makes the AI system behave more like another application client rather than a privileged superuser.

What I learned building it

The biggest lesson was that adding AI to a SaaS application is not mainly about calling an LLM API.

The difficult part is everything around the model.

I had to think about:

Who is making the request?
What context does the agent need?
What data can it access?
What tools should it have?
What actions can it perform?
Which operations require confirmation?
How does tenant isolation continue to work?
How do I prevent the AI layer from bypassing authorization?
How do I provide product knowledge without exposing private customer data?

The model is only one component of that system.

The architecture today

The resulting architecture looks roughly like this:

                         User
                           │
                           ▼
                      AI Request
                           │
                           ▼
                     Agent Context
                           │
                           ▼
                       Orchestrator
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        Personal       Organization     CRM
         Agent            Agent         Agent
             │             │             │
             └─────────────┼─────────────┘
                           │
                           ▼
                      Model Router
                           │
                           ▼
                       LLM / Model
                           │
                           ▼
                         Tools
                           │
                           ▼
                     Authorization
                           │
                           ▼
                       Validation
                           │
                    ┌──────┴──────┐
                    │             │
                 Read          Mutation
                    │             │
                    │        Confirmation
                    │             │
                    └──────┬──────┘
                           ▼
                    Business Logic
                           │
                           ▼
                       Database
                           │
                           ▼
                         RLS

It's still evolving, but this structure gives me something much more useful than a single chatbot bolted onto the side of the CRM.

Final thoughts

Building an AI assistant inside a SaaS product changed how I think about AI architecture.

The interesting question isn't just:

"Which model should I use?"

It's:

"What should this model be allowed to know and do?"

For me, scoped agents became a practical way to answer that question.

Each agent gets a defined purpose, context, and set of capabilities. The application remains responsible for authorization, validation, and execution.

The result is an AI system that can interact with a real SaaS application without treating the LLM as an all-powerful user.

And that's probably the biggest lesson I've taken from building it:

AI doesn't replace application architecture. It makes good application architecture even more important.

uniThread is still evolving, and so is its AI architecture. But building it has been a great way to learn what happens when LLMs move beyond chat and start becoming actual components of a software system.

How I Built Multi-Tenant Data Isolation for My SaaS CRM with PostgreSQL RLS

Jestony Silvano — Thu, 10 Sep 2026 16:00:33 +0000

How I Built Multi-Tenant Data Isolation for My SaaS CRM with PostgreSQL RLS

When I started building uniThread CRM, I wanted it to be more than just a basic CRUD project. I wanted to actually understand what it takes to build a SaaS application where multiple organizations share the same system without ever seeing each other's data.

That led me to one of the harder questions I had to answer while building it:

How do I make sure users can only ever access data belonging to their own organization?

My answer ended up being a combination of PostgreSQL Row-Level Security (RLS) and authorization logic on the backend. Here's how I got there, and why I didn't just trust one layer to handle it.

The Obvious Requirement

The rule is simple to state: Organization A should never be able to access Organization B's data. Simple to say, less simple to guarantee.

The easy way to handle this is to just add an organization_id filter to every database query in the backend. And that works... until someone forgets to add it. One missed WHERE clause on one endpoint, and suddenly you've got a data leak. I didn't want tenant isolation to depend entirely on every developer (including future me) remembering to add that filter every single time.

That's what got me looking into PostgreSQL RLS.

Designing Around Organizations

For any organization-specific CRM data, I use an organization_id column to tie each record to the organization that owns it. Nothing fancy, just:

CREATE TABLE leads (
    id UUID PRIMARY KEY,
    organization_id UUID NOT NULL,
    name TEXT NOT NULL
);

That gives every lead a clear, explicit relationship to an organization. It sounds almost too simple to matter, but it's the foundation everything else builds on top of.

Bringing in Row-Level Security

PostgreSQL RLS lets the database itself decide which rows a query is allowed to see, instead of leaving that entirely up to the application code.

First, you turn it on for the table:

ALTER TABLE leads ENABLE ROW LEVEL SECURITY;

Then you write a policy that only allows access to rows belonging to the current user's organization:

CREATE POLICY "Users can access their organization leads"
ON leads
FOR SELECT
USING (
    organization_id = get_user_organization_id()
);

Once that's in place, tenant isolation stops being something only my application layer is responsible for. The database is now enforcing it too. Even if I mess something up in the app code, there's still a wall between organizations at the data layer. That extra layer of protection is really what sold me on this approach.

Why I Didn't Just Rely on RLS

Even with RLS in place, I still wanted the backend to own authorization and business logic. RLS is great at stopping cross-tenant access, but it's not really designed to handle things like "can an Agent delete a lead" or "is this user even allowed to hit this endpoint."

So the backend follows a fairly standard layered structure:

Request
   ↓
Controller
   ↓
Service
   ↓
Repository
   ↓
PostgreSQL

The backend handles authentication, role-based access control, organization context, business rules, and validation. Then PostgreSQL adds its own layer on top through RLS.

The point isn't to make one layer do everything. It's to let each layer do what it's actually good at.

Roles

Right now, uniThread has three organization-level roles:

Owner
Manager
Agent

A user's role determines what they're allowed to do inside their organization.

Working through this part is actually what made the difference between authentication and authorization click for me in a way it never had before.

Authentication asks: who are you?

Authorization asks: what are you allowed to do?

And tenant isolation asks a third, separate question: which organization's data are you even allowed to touch?

They sound like variations of the same idea when you read about them, but once you're actually implementing all three at once, the differences become a lot more obvious.

What I Learned

Before building uniThread, my mental model of auth was basically:

Login → JWT → Authenticated User

That's it. That was the whole picture in my head.

Building something multi-tenant broke that mental model pretty quickly. Getting a user authenticated is really just the starting point. After that you still have to figure out what they can access, what actions they're allowed to take, and how the database itself should be protecting that data regardless of what the app layer does.

It also made me a lot more deliberate about where security checks actually belong, and made me think harder about what happens the day a developer forgets to add one.

The Result

Between organization-scoped data, backend authorization, and PostgreSQL RLS, uniThread now has a decent foundation for keeping tenant data properly separated.

More than the technical result, though, this was one of the first parts of the project that pushed me past "just build the CRUD feature" and into actually thinking about architecture, security, data ownership, and what happens as the system grows.

What I'd Do Differently

If I were starting uniThread over, I'd think about tenant isolation a lot earlier than I did. It's way easier to bake organization ownership into your schema from day one than to retrofit it after you've already built a pile of features on top of a shaky foundation.

I'd also spend more time up front defining authorization rules, instead of discovering the edge cases one at a time while implementing individual features and going "oh... wait."

Final Thoughts

uniThread started out as just "I want to build a CRM." Somewhere along the way it turned into a much better lesson in how SaaS applications are actually put together under the hood.

Multi-tenancy was one of those topics that looked simple from the outside and turned out to be way more interesting than expected once I actually had to implement it myself.

I'm still learning as I go, but honestly, that's a big part of why I keep building projects like this. The interesting part was never just making the app work. It's figuring out how to make it work correctly as things get more complicated.

Juniors! Overengineer Your Projects

Jestony Silvano — Wed, 09 Sep 2026 11:15:17 +0000

title: "Juniors! Overengineer Your Projects"
published: true
description: "Stop optimizing for the number of projects you can finish. Build fewer things, go deeper, use AI intelligently, break your own code, and learn how real software systems work."
tags: "ai, beginners, webdev, programming, softwareengineering"

Juniors! Overengineer Your Projects

If you're a junior developer trying to land your first software job, you've probably heard some version of this advice:

"Build more projects."

So you build another one.

Then another.

A portfolio website.
A weather app.
A todo app.
A Netflix clone.
A CRUD application.

And eventually, you have a GitHub full of repositories. But how much did you actually learn? I think we should approach this differently.

Stop Optimizing for the Number of Projects

You don't need to prove that you can start 20 projects. You need to prove that you can understand, build, debug, and improve software.

Instead of asking:

"How quickly can I finish this?"

Try asking:

"How far can I take this?"

That's where things get interesting.

1. Don't Be Afraid to Overengineer

Obviously, don't build a distributed microservice architecture for a todo app just because you can. That's not the point. The point is that complexity can create opportunities to learn. Take a project further than you initially planned. Add authentication. Design a proper database. Think about authorization. Add role-based access control. Handle errors properly. Think about concurrency. Add caching. Write tests. Build background jobs. Think about how the system behaves when something fails. Deploy it. Monitor it. Then break it. Then fix it. You might spend weeks building something that could have been hacked together in three days. And that's okay. If those extra weeks made you understand something you didn't understand before, you didn't waste them. You learned.

2. Read Your Own Code

This one sounds obvious, but I think it's seriously underrated.

Read the code you wrote.

Not just while you're writing it.

Come back to it later.

Look at an old function and ask:

Why did I build it this way?
Do I still understand this?
Would I design this differently now?
Is this actually maintainable?
What happens when this fails?
Why does this abstraction exist?
Did I solve the actual problem, or did I just make the code more complicated?

Then change it.

Refactor it.

Delete it.

Rewrite it.

Your old code is one of the best teachers you'll ever have because it shows you exactly what you used to think you understood.

3. We're Still Early in the AI Era

This is probably one of the most interesting times to be learning software development.

AI can write code incredibly quickly.

So use it.

Seriously.

Don't pretend AI doesn't exist just because you want to "learn properly."

Leverage it.

Ask it to explain concepts you don't understand.

Ask it to explain unfamiliar code.

Ask it to compare architectural approaches.

Ask it to review your database design.

Ask it to find edge cases.

Ask it to challenge your assumptions.

Ask it questions you would normally spend hours trying to formulate yourself.

But there's a catch.

Don't Let AI Become Your Brain

The quality of the answer you get is heavily influenced by the quality of the question you ask.

And the quality of your question depends on the context you can provide.

Build context.

Learn the problem first.

Understand your system.

Understand the constraints.

Understand what you're trying to solve.

Then ask AI.

If you give it vague questions and no context, you'll often get vague solutions.

If you understand the problem and provide meaningful context, AI becomes a much more powerful learning tool.

And don't be afraid to use smaller models or solve something yourself before reaching for the biggest model available.

Sometimes struggling with a problem for an hour teaches you more than getting the answer in ten seconds.

4. Build Systems, Not Just Projects

There's a difference between building a project and building a system.

A project can be:

"I built a CRUD application."

A system makes you ask:

"What happens when 10,000 users use this?"

Then you start thinking differently.

You start thinking about:

Architecture
Data modeling
Security
Performance
Caching
Authentication
Authorization
Observability
Deployment
Failure recovery
Scalability
Maintainability

You don't necessarily need to implement all of these.

But even thinking about them changes the way you understand software.

5. Build Something That Is Actually Yours

Please, build another tutorial project if you want to. There's nothing wrong with that. But eventually, build something original. Build something because you had an idea, because you noticed a problem.

"I have no idea how I'm going to build this."

That's where the fun starts. You might fail. Good. You might rewrite half of it. Even better. You might discover that your original architecture was terrible. Perfect. Now you have something to learn from.

Don't Maximize Output. Maximize Learning.

There's a strange pressure among junior developers to constantly produce.

More GitHub repositories.
More projects.
More technologies.
More certificates.
More tutorials.
More AI-generated code.
More, more, more.

But software development isn't a race to produce the most code. You can build 30 projects and barely understand any of them. Or you can build one project that forces you to learn databases, APIs, authentication, security, deployment, architecture, testing, debugging, and system design.

Which developer do you think learned more?

So if you're a junior developer trying to get your first job:

Don't be afraid to take your project too far.
Don't be afraid to spend too much time learning.
Don't be afraid to read your own code.
Don't be afraid to break things.
Don't be afraid to rewrite things.
Don't be afraid to ask AI questions.
Don't be afraid to work without AI sometimes.

And most importantly:

Don't Be Afraid to Build Something Bigger Than You Know How to Build

Because that's how you learn how to build it.