As I continued developing FlowOps, one of the most interesting engineering questions was not simply how to add AI to the product. The more important question was where AI could genuinely reduce operational work without allowing it to take control of business decisions that should remain predictable, auditable and human controlled.
Service operations contain a mixture of structured and unstructured information. Customers describe problems in their own words. Managers interpret requests. Team members update jobs. Work moves through different states, and important actions may require review or approval.
Traditional automation is very good when the expected behaviour is known in advance. AI becomes useful when information first needs to be interpreted.
That distinction became the foundation for how I approached AI assisted workflow automation in FlowOps.
Core Design Principle
Customer or User Input
↓
AI Interpretation
↓
Suggested Structured Data
↓
Human Review
↓
Application Validation
↓
Workflow Rules
↓
Controlled Action
The Problem with Manual Request Capture
Customer requests rarely arrive as perfectly structured data.
A customer may write:
Our air conditioning stopped cooling properly yesterday. Someone can visit after 3 PM on Thursday. Please call before arriving because the office entrance is locked.
A business user may then manually copy this into several fields:
Service type
Problem description
Preferred date
Preferred time
Customer instruction
This is repetitive, but it also requires interpretation.
That makes it a good place for AI assistance.
Turning Natural Language into Structured Data
Instead of asking the user to fill every field manually, FlowOps can use AI to interpret the request and suggest values.
{
"service_type": "Air conditioning service",
"issue": "Air conditioning unit is not cooling correctly",
"preferred_day": "Thursday",
"preferred_time": "After 15:00",
"customer_instruction": "Call before arrival because the entrance is locked"
}
The result is useful because unstructured information has been converted into fields the workflow can understand.
But I do not want those values written directly into the job without review.
AI Suggests, the User Confirms
The design I prefer is simple:
Raw Customer Request
↓
AI Reads Request
↓
Suggested Fields
↓
User Reviews or Edits
↓
User Confirms
↓
FlowOps Creates the Job
The important word here is suggested.
AI helps reduce manual effort, but the person using the system remains responsible for deciding whether the extracted information is correct.
Do Not Allow AI to Invent Missing Information
One of the strongest rules I would apply to AI assisted request capture is:
Extract what is present. Do not invent what is missing.
If the customer does not provide an address, the AI should not guess one.
If no appointment date is given, it should not create one.
A structured response can make missing fields explicit.
{
"service_type": "Heating repair",
"issue": "Heating system not working",
"preferred_date": null,
"preferred_time": null,
"address": null
}
This gives the user a clear indication of what still needs to be completed manually.
A Controlled AI Prompt
The AI instruction itself should make these boundaries clear.
Extract structured service request information
from the customer message.
Return:
1. service_type
2. issue
3. preferred_date
4. preferred_time
5. customer_instruction
Rules:
- Use only information present in the request.
- Do not invent missing details.
- Return null when information is unavailable.
- Keep the original meaning.
- Do not create or update a job.
- Do not assign a team member.
- Do not change workflow status.
- The user will review the result before it is applied.
The prompt defines the AI as an interpretation tool rather than a workflow authority.
Schema Validation Comes After AI
Even after the user accepts the AI suggestion, the application should validate the data.
For example:
def validate_job_input(data):
errors = []
if not data.get("service_type"):
errors.append(
"Service type is required."
)
if not data.get("issue"):
errors.append(
"Issue description is required."
)
return errors
AI may prepare the information.
Application logic determines whether the information is valid.
Workflow Automation Begins After Validation
Once a valid job exists, traditional workflow automation becomes more appropriate.
FlowOps can then apply deterministic rules.
AI Interprets Request
↓
User Confirms
↓
Application Validates
↓
Job Created
↓
Workflow Engine Takes Control
Keep Workflow Transitions Deterministic
A job should not move through the lifecycle because an AI model thinks the next state is appropriate.
FlowOps can define allowed transitions explicitly.
ALLOWED_TRANSITIONS = {
"PENDING": {
"SCHEDULED"
},
"SCHEDULED": {
"ON_ROUTE"
},
"ON_ROUTE": {
"ARRIVED"
},
"ARRIVED": {
"STARTED"
},
"STARTED": {
"COMPLETED"
},
"COMPLETED": {
"DELIVERED"
}
}
This makes workflow behaviour predictable and testable.
The AI Should Not Change Job Status
Imagine a team member writes:
All finished here. The customer tested the system and everything is working now.
AI may correctly understand that the work sounds complete.
But I would not allow it to automatically change:
STARTED → COMPLETED
Instead, it could suggest:
This note indicates that the work may be complete. Would you like to mark this job as Completed?
The team member still performs the workflow action.
Human Controlled Decisions
This became the most important architectural principle in the AI design.
AI = Understand and Suggest
↓
Human = Review and Decide
↓
Application = Validate
↓
Workflow Engine = Execute Controlled Transition
The user should always understand when they are reviewing an AI suggestion and when they are performing a real business action.
AI Can Help with Job Summaries
Request capture is not the only place where interpretation can reduce operational effort.
A long running job may contain:
AI can turn this into a concise operational summary.
Customer reported an air conditioning cooling issue. The job was scheduled for Thursday afternoon and assigned to James. The technician arrived at 15:18 and started work at 15:24. A faulty connection was identified and repaired. Work has now been completed and is awaiting review.
This can help a manager understand the history without reading every individual event.
The Source of Truth Must Remain the Workflow Data
AI summaries should never replace the actual activity history.
FlowOps should continue storing the structured source data:
[
{
"time": "15:02",
"event": "ON_ROUTE"
},
{
"time": "15:18",
"event": "ARRIVED"
},
{
"time": "15:24",
"event": "STARTED"
},
{
"time": "16:11",
"event": "COMPLETED"
}
]
AI summarises this information.
It does not replace it.
AI Can Help Identify Missing Information
Another useful pattern is detecting when a request is incomplete.
Suppose the customer says:
My boiler is leaking. I need someone tomorrow.
AI can extract what is available and indicate what still needs to be collected.
{
"service_type": "Boiler repair",
"issue": "Boiler is leaking",
"preferred_date": "Tomorrow",
"preferred_time": null,
"missing_information": [
"Preferred time"
]
}
This allows the system to assist the business user without fabricating an answer.
AI Can Suggest, but Not Choose, Assignment
Assignment is another area where AI could eventually provide useful assistance.
For example, the platform may already know:
[
{
"user": "James",
"active_jobs": 2
},
{
"user": "Sarah",
"active_jobs": 5
},
{
"user": "Daniel",
"active_jobs": 1
}
]
AI could potentially present:
Daniel currently has the lowest active workload. James also has capacity. Review availability before assigning the job.
The manager still decides who receives the work.
Why I Would Not Let AI Assign Automatically
Workload alone may not capture every business consideration.
A manager may know:
Who has the right experience
Who is already travelling nearby
Who has another priority later
Whether the customer has requested someone specific
AI may support the decision.
It should not remove contextual business judgement.
Review Is Another Human Control Point
In FlowOps, completing work can lead to a review stage rather than immediately closing the job.
AI could summarise the completed work for the reviewer:
Work Summary:
Technician investigated the cooling issue, identified a loose electrical connection, repaired the connection and tested the system. The final note states that normal cooling was restored.
But the AI should not choose:
Close Job or Request Reattempt
That remains a reviewer decision.
Protect Multi Tenant Boundaries
Because FlowOps is a multi tenant SaaS application, AI context must respect the same tenant boundaries as every other product feature.
The AI layer should never search across unrelated businesses.
Authenticated User
↓
Tenant Resolution
↓
Permission Check
↓
Retrieve Allowed Records
↓
Build AI Context
↓
Generate Response
AI does not create a new security boundary.
It must operate inside the existing one.
Permissions Apply Before AI Context Is Built
Imagine a Team Member is allowed to view only assigned work.
The AI assistant should not receive every job in the organisation simply because the model could technically summarise them.
The correct flow is:
user_jobs = get_jobs(
tenant_id=current_user.tenant_id,
assigned_to=current_user.user_id
)
ai_context = build_context(
user_jobs
)
Access filtering should happen before AI receives the data.
Protect Sensitive Information
Operational data can contain information that should not be placed unnecessarily into AI context.
Examples include:
Context should therefore be reduced to what is actually required for the AI task.
Minimise AI Context
If the task is summarising a customer request, the AI may only need:
{
"request_text":
"The heating stopped working this morning..."
}
It may not need the complete customer history, account details and every previous job.
Smaller context also makes the AI task clearer.
Separate Facts from AI Suggestions
Another design choice I consider important is clearly separating what FlowOps knows from what AI has inferred.
Known
Customer requested Thursday after 3 PM.
AI Interpretation
Service type appears to be air conditioning repair.
Missing
No specific technician preference was provided.
This makes the interface more transparent.
Confidence Can Help with Review
AI suggestions are not always equally clear.
A structured result could include confidence:
{
"service_type": {
"value": "Air conditioning repair",
"confidence": "high"
},
"preferred_time": {
"value": "After 15:00",
"confidence": "high"
},
"priority": {
"value": null,
"confidence": "insufficient_information"
}
}
Low confidence or missing information can be highlighted for manual attention.
AI Can Improve Operational Search
As operational history grows, users may eventually want to ask questions naturally.
For example:
Show me the jobs awaiting review today.
AI can interpret the intent:
{
"resource": "jobs",
"filter": {
"review_status": "AWAITING_REVIEW",
"date": "TODAY"
}
}
FlowOps can then execute the actual query using its normal tenant and permission rules.
AI Interprets the Query, the Platform Executes It
User Question
↓
AI Intent Interpretation
↓
Structured Filter
↓
Permission Validation
↓
Tenant Scoped Database Query
↓
Results
↓
AI Friendly Summary
Do Not Give the AI Arbitrary Database Access
I would not allow an AI model to generate unrestricted SQL and execute it against production data.
Instead, AI should map user intent to supported application operations.
AI: Interpret what the user wants.
Application: Decide which approved query or action can satisfy it.
Auditing AI Assisted Actions
If AI contributes to a user action, I want that interaction to remain understandable.
A simple audit record could store:
{
"action": "AI_ASSISTED_JOB_CREATE",
"requested_by": "user_204",
"ai_suggestion_used": true,
"user_confirmed": true,
"job_id": "job_10482"
}
The record does not need to expose unnecessary AI internals.
It simply makes it clear that AI assistance was used and a human confirmed the action.
Feedback Improves AI Assistance
One useful product loop is allowing users to correct AI suggestions.
Imagine AI suggests:
Service Type: Electrical repair
but the user changes it to:
Service Type: Appliance repair
That correction is useful product feedback.
Over time, patterns in corrections can reveal where prompts, categories or product design need improvement.
AI Should Fail Safely
AI may be unavailable, slow or return an unusable response.
The core workflow should still work.
AI Available?
↓
Yes → Suggest Structured Fields
No → Continue with Manual Form
AI should improve the product.
It should not become a dependency that prevents basic service operations from continuing.
Separate AI Failure from Workflow Failure
This separation also makes error handling easier.
If AI request interpretation fails:
AI assistance is temporarily unavailable. You can continue creating the job manually.
The user should not receive:
FlowOps is unavailable.
The AI feature and the core workflow are different system responsibilities.
Rate Limiting AI Requests
AI operations can also consume more resources than normal application actions.
It therefore makes sense to control usage.
rate_limit_key = (
f"tenant:{tenant_id}:ai"
)
Tenant aware limits can protect the platform and help keep usage predictable.
Where AI Adds Value in FlowOps
Looking across the product, I see several areas where AI can provide useful assistance.
Request interpretation
Convert customer messages into suggested structured fields.
Missing information detection
Highlight important information that was not provided.
Operational summaries
Summarise long job histories for managers and reviewers.
Natural language search
Translate user questions into supported platform filters.
Workload context
Surface relevant information before a manager assigns work.
Review assistance
Summarise the work completed before a human makes the final review decision.
Where AI Should Not Be the Authority
There are also clear areas where I prefer deterministic controls.
These areas need predictable behaviour and clear responsibility.
A Four Layer Responsibility Model
AI Layer
Interpret unstructured information, summarise context and provide suggestions.
Human Layer
Review suggestions, apply judgement and approve important business decisions.
Application Layer
Validate fields, users, permissions, tenant context and workflow rules.
Automation Layer
Execute approved and predictable actions such as notifications, state changes and tracking updates.
End to End AI Assisted Request Flow
Customer Request
↓
FlowOps Request Capture
↓
AI Extraction
↓
Suggested Service + Issue + Schedule Information
↓
Human Review
↓
Required Field Validation
↓
Job Created
↓
Manager Assignment
↓
Workflow Execution
↓
Team Completes Work
↓
AI Summarises Activity
↓
Human Review
↓
Close or Reattempt
Full Technical Architecture
Owner / Manager / Team Member
↓
FlowOps User Interface
↓
Authentication
↓
Tenant Context + Permissions
↓
Application API
↓
┌───────────────────────────────┐
AI Assistance Layer
Request Interpretation
Summaries
Suggestions
└───────────────────────────────┘
↓
Human Confirmation
↓
Validation + Workflow Engine
↓
Jobs + Customers + Teams + Review
↓
Database
↓
Notifications + Tracking + Audit
↓
Operational Dashboard
Why Human Control Makes the AI More Useful
At first, adding human review may appear to reduce automation.
I see it differently.
Human controlled AI allows the product to automate the part of the workflow where automation is genuinely useful while keeping responsibility in the correct place.
Without AI
User manually interprets and enters every piece of information.
Uncontrolled AI
AI interprets information and makes business decisions without sufficient safeguards.
Human controlled AI
AI reduces interpretation effort, the user confirms important decisions, and deterministic software controls execution.
The third model is the one I find most practical for operational software.
What This Changed in My Product Thinking
Earlier in my AI journey, I was mainly thinking about questions such as:
Can AI analyse these logs?
Can AI identify useful operational patterns?
Can AI explain an incident more quickly?
Building AI features inside FlowOps introduced a more product focused question:
How can AI become part of a real customer workflow in a way that saves time, remains understandable and never bypasses the rules that protect the business?
That was a much more interesting engineering challenge.
AI Became a Product Capability, Not a Separate Feature
Another lesson was that AI becomes more useful when it is integrated into an existing workflow rather than placed into a separate chatbot simply because AI is available.
In FlowOps, the useful question became:
Where is the user currently performing repetitive interpretation work, and can AI reduce that effort without changing who is responsible for the decision?
That is why request capture became a natural AI entry point.
My Main Engineering Principles
1. AI should assist interpretation.
Use it where information is unstructured or difficult to summarise.
2. Humans should control important decisions.
Assignment, review and workflow decisions should remain understandable and accountable.
3. Deterministic software should enforce rules.
Permissions, tenant isolation and workflow transitions should not depend on model judgement.
4. AI should never invent required business data.
Missing information should remain missing until supplied or confirmed.
5. AI should fail independently.
The core product should remain usable when AI is unavailable.
6. AI should operate inside existing security boundaries.
Tenant and role permissions are applied before AI receives context.
7. The source of truth remains structured application data.
AI summaries and suggestions should never replace operational records.
8. Users should know when AI is assisting them.
Suggestions should be distinguishable from confirmed product data.
The Journey Behind the Architecture
Looking back, this design connects many parts of my engineering journey.
DevOps Automation
↓
Predictable Execution
↓
AI Log Analysis
↓
AI Assisted Interpretation
↓
Platform Engineering
↓
Controlled Self Service
↓
Multi Tenant SaaS
↓
Roles + Permissions + Isolation
↓
FlowOps
↓
AI Assisted Product Workflows
↓
Human Controlled Decisions
Conclusion
In this article, I explored how I approached AI assisted workflow automation in FlowOps.
The goal was never to make AI responsible for running the business.
The goal was to identify where AI could reduce repetitive interpretation work while keeping product behaviour predictable and human controlled.
The architecture combines:
Natural language request interpretation
Structured field extraction
Missing information detection
Human review
Application validation
Deterministic workflow transitions
AI assisted job summaries
Review assistance
Natural language operational search
Tenant aware AI context
Role based permissions
Sensitive data protection
AI usage auditing
Independent AI failure handling
Human controlled business decisions
For me, the strongest model is:
AI = Interpretation
↓
Human = Decision
↓
Application = Validation
↓
Automation = Controlled Execution
This allows AI to become genuinely useful inside a real SaaS product without making the system dependent on unpredictable model decisions.
Building this approach into FlowOps brought together the different areas I had been exploring throughout my journey: DevOps automation, AI assisted operations, platform engineering, multi-tenant SaaS architecture and product development.
More importantly, it changed the way I think about AI product design. Innovation is not simply adding more autonomy. Sometimes the better innovation is designing the right boundary between AI, software automation and human judgement.
My takeaway: The most valuable role for AI in FlowOps is not replacing the people who understand the operation. It is reducing the repetitive work around understanding requests, organising information and surfacing context so those people can make better decisions more efficiently. The workflow remains controlled, the user remains responsible, and AI becomes an assistance layer inside the product rather than the authority behind it.
Join the conversation! Your thoughts help the community grow.