Building a chatbot is surprisingly easy.
Building an AI system that belongs inside real production software is not.
A basic prototype might look something like this:
const response = await openai.responses.create({
model: "gpt-5",
input: "What maintenance problem is the user describing?"
});
You send text to a model.
The model sends text back.
That is exciting—and incredibly useful for learning.
But the moment the AI needs to create a work order, retrieve information from a database, identify a building, respect user permissions, call an external API, or operate across multiple customers, the problem changes completely.
You are no longer building a chatbot.
You are building a software system in which an AI model is one component.
That distinction has become one of the most important lessons I have learned while building AI-enabled applications.
- The LLM Should Not Be Your Application
Early AI prototypes often place the language model in the center of everything:
User
↓
LLM
↓
Answer
That works when the goal is conversation.
Production applications usually need something closer to this:
┌──────────────┐
│ User │
└──────┬───────┘
│
▼
┌──────────────┐
│ Application │
│ API │
└──────┬───────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ LLM │ │ Database │ │ Services │
└──────────┘ └──────────┘ └──────────┘
│
▼
Structured decision
The model becomes a reasoning and language layer.
The application remains responsible for things like:
authentication
authorization
database integrity
business rules
audit history
API validation
transactions
tenant isolation
security
error handling
That separation matters.
An LLM should not decide whether a user is authorized to delete an invoice.
Your application should.
- Natural Language Has to Become Structured Data
Suppose someone writes:
The AC in conference room 204 isn't cooling. It started this morning and we have a client meeting at 2 PM.
A human immediately extracts useful information:
{
"issueType": "HVAC",
"location": "Conference Room 204",
"problem": "Not cooling",
"priority": "High"
}
This is where LLMs become extremely valuable.
Instead of forcing the user through ten form fields, the system can accept natural language and convert it into structured information.
But there is an important architectural rule:
LLM output should be treated as untrusted input.
If the model returns:
{
"priority": "EXTREMELY_SUPER_CRITICAL"
}
your backend should reject it.
A validation layer should enforce something like:
enum Priority {
LOW = "LOW",
MEDIUM = "MEDIUM",
HIGH = "HIGH",
EMERGENCY = "EMERGENCY"
}
The AI proposes.
The application validates.
- Tool Calling Changes Everything
A chatbot only talks.
An AI application can act.
For example, a maintenance assistant might have tools such as:
search_property()
find_asset()
create_service_request()
lookup_work_order()
check_request_status()
find_vendor()
Now imagine the user says:
What's happening with the leaking-pipe request I submitted yesterday?
The model should not hallucinate an answer.
Instead:
User question
↓
LLM determines intent
↓
lookup_work_order(...)
↓
Application queries database/API
↓
Real result
↓
LLM explains result naturally
That is an enormous shift.
The LLM is no longer the source of truth.
The system of record is.
- Agents Need Boundaries
The word agent is being used everywhere right now.
But giving an LLM access to tools does not mean it should have unlimited authority.
Consider an AI system with these capabilities:
READ work orders
CREATE work orders
UPDATE work orders
DELETE work orders
APPROVE invoices
SEND emails
Those actions should not all have equal trust.
A useful approach is to separate tools by risk.
For example:
LOW RISK
────────────
Search
Summarize
Read status
Retrieve documentation
MEDIUM RISK
────────────
Create draft
Create service request
Update noncritical fields
HIGH RISK
────────────
Approve payment
Delete records
Change permissions
Execute financial transactions
Higher-risk actions can require deterministic checks or human approval.
The goal is not maximum autonomy.
The goal is useful autonomy with controlled authority.
- Multi-Tenant AI Is Mostly a Software Architecture Problem
Imagine a SaaS platform serving:
Company A
Company B
City C
School District D
The AI should never accidentally retrieve Company A's data while assisting Company B.
This means tenant context must exist outside the language model.
For example:
Request
↓
Authenticate user
↓
Resolve tenant
↓
Apply permissions
↓
Query tenant-scoped data
↓
Send approved context to model
Not:
"Dear AI, please remember not to access another customer's data."
Prompts are not a security boundary.
Software architecture is.
- AI Systems Need Deterministic Components
One of the strange things about building with LLMs is combining probabilistic behavior with deterministic software.
The LLM might interpret:
It's unbearably hot in the server room.
as:
Issue = HVAC
Location = Server Room
Priority = Emergency
That interpretation may involve probabilistic reasoning.
But once the application accepts those fields, deterministic systems take over:
Validate location
Validate issue category
Verify user's property access
Generate request ID
Store database record
Write audit event
Notify responsible team
This architecture gives us the best of both worlds.
AI handles ambiguity.
Software handles certainty.
- The Database Still Matters
AI sometimes creates the impression that traditional application engineering is becoming less important.
My experience has been the opposite.
The more capable the AI becomes, the more important good system architecture becomes.
You still need:
PostgreSQL
API design
authentication
authorization
schemas
indexes
transactions
logging
queues
caching
monitoring
testing
deployment pipelines
LLMs do not eliminate these things.
They create a new interface on top of them.
- Context Is an Engineering Resource
Developers often talk about giving an LLM "more context."
More is not always better.
Suppose the system has access to:
200,000 work orders
12,000 assets
500 buildings
thousands of invoices
policies
contracts
manuals
vendor documentation
You should not simply throw everything into the prompt.
Instead:
User request
↓
Determine intent
↓
Retrieve relevant records
↓
Apply permissions
↓
Reduce context
↓
Send relevant information to model
Good context engineering is partly an information-retrieval problem.
It is also a software-design problem.
- Observability Becomes Essential
Traditional applications can log:
POST /work-orders
Status: 201
Duration: 142 ms
AI applications need additional observability.
You may want to know:
Which model was used?
Which tools were called?
Why was a particular tool selected?
How many tokens were consumed?
How long did inference take?
Did validation fail?
Was human approval required?
What structured output was returned?
Without this information, debugging AI behavior becomes extremely difficult.
- Production AI Is a System, Not a Model
This has become my mental model:
┌──────────────────┐
│ Human │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Application │
│ Interface │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ AI Orchestration│
└────────┬─────────┘
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Models Tools Retrieval
│ │ │
└───────────┼───────────┘
▼
┌──────────────────┐
│ Business Logic │
└────────┬─────────┘
▼
┌──────────────────┐
│ Data + Services │
└──────────────────┘
The LLM may be the most fascinating component.
But it is still a component.
What Changed My Thinking
When I first started experimenting with AI integrations, the fascinating question was:
What can the model do?
As the systems became more serious, the question changed.
Now I increasingly ask:
What should the model do, and what should the surrounding software guarantee?
That is a much more useful engineering question.
The future of AI software will not simply be larger models connected directly to users.
It will be carefully designed systems where language models, deterministic software, data, APIs, humans, and autonomous tools work together.
And for software engineers, I think that makes this moment especially interesting.
We aren't replacing software engineering with AI.
We're adding an entirely new computational layer to software engineering.
What I'm Exploring Next
I'm currently exploring this intersection through:
agentic AI
LLM tool calling
production AI architecture
multi-tenant SaaS
autonomous systems
AI workflow automation
educational AI systems
In future posts, I plan to go deeper into individual parts of this architecture—including tool calling, agent permissions, multi-tenancy, context engineering, and the relationship between neural networks, transformers, and modern LLMs.
If you're building production AI systems too, I'd love to compare architectures and lessons learned.
