CASE STUDY
SaaS
WebApp
Turning Engineering heavy Agent building process into a
Product led Agent building experience
Turning engineering heavy agent building process into a Product led Agent building experience
STAKEHOLDERS
2x Software Engineers
AI Engineer
Product Manager
MY ROLE
Product Designer
PROJECT DURATION
4 weeks
LAST UPDATED
20th February, 2026
Click here to play with the prototype
CONTEXT
Nolana builds AI support agents for Insurance and Banking that do more than just answering questions.
Cancel subscription
UPDATE CUSTOMER DETAILS
CHANGE BILLING DATES
CHECK CLAIM STATUS
GIVE MISSING INFORMATION
Can you change my credit card payment date to 28th of every month going forward?
Fetched customer info from CRM
Read knowledgebase SOP
Read knowledgebase SLA
Executed Procedure Change billing date
Sure! Just so you know that you can change the billing cycle only once every 90 days. Happy to proceed?
PROBLEM
The agents worked. The problem was how we built them. Every customer setup depended heavily on engineering, which slowed launches, made iteration expensive, and limited how many customers we could onboard at once.
Time consuming bespoke builds
Each customer agent had to be hand-built from SOPs, prompts, tools, and integrations.
Slow iteration speed
Small prompt or workflow tweaks had to go through engineering before they could be tested.
Difficulty with scaling onboarding
More implementation work instead of repeating a scalable product flow.
Each customer request was a new engineering ticket
GTM and CS couldn’t make changes themselves, so post-launch tweaks became dev requests.
OPPORTUNITY
How might we make agent-building feel as simple as writing a document, while still giving the system enough structure to behave reliably?
Turn this
to this
Turn this
to this
GETTING STARTED
I started by working with engineering and product to turn implementation logic into simple concepts a non-technical user could understand within the product.
Engineering Abstraction
Translated code concepts into product led agent building primitives in collaboration with engineers
NODES
PROMPT
TOOLS
Data connectors
IF\ELSE
EXTERNAL PROCEDURES
TERMINATE
Competitor Analysis
Studied other agent/workflow building products such as N8N, retool and Intercom on Mobbin
COMPETITOR ANALYSIS
great tool and branch visibility
Logic based
Graph first approach
Case studies
Say hello 👋
designedbyhari@gmail.com
© 2025 by Hariharan Ramesh
Case studies
Say hello 👋
designedbyhari@gmail.com
© 2025 by Hariharan Ramesh
CASE STUDY
SaaS
WebApp
Turning Engineering heavy Agent building process into a
Product led Agent building experience
Turning engineering heavy agent building process into a Product led Agent building experience
STAKEHOLDERS
2x Software Engineers
AI Engineer
Product Manager
MY ROLE
Product Designer
PROJECT DURATION
4 weeks
LAST UPDATED
20th February, 2026
Click here to play with the prototype
CONTEXT
Nolana builds AI support agents for Insurance and Banking that do more than just answering questions.
Cancel subscription
UPDATE CUSTOMER DETAILS
CHANGE BILLING DATES
CHECK CLAIM STATUS
GIVE MISSING INFORMATION
Can you change my credit card payment date to 28th of every month going forward?
Fetched customer info from CRM
Read knowledgebase SOP
Read knowledgebase SLA
Executed Procedure Change billing date
Sure! Just so you know that you can change the billing cycle only once every 90 days. Happy to proceed?
PROBLEM
The agents worked. The problem was how we built them. Every customer setup depended heavily on engineering, which slowed launches, made iteration expensive, and limited how many customers we could onboard at once.
Time consuming bespoke builds
Each customer agent had to be hand-built from SOPs, prompts, tools, and integrations.
Slow iteration speed
Small prompt or workflow tweaks had to go through engineering before they could be tested.
Difficulty with scaling onboarding
More implementation work instead of repeating a scalable product flow.
Each customer request was a new engineering ticket
GTM and CS couldn’t make changes themselves, so post-launch tweaks became dev requests.
OPPORTUNITY
How might we make agent-building feel as simple as writing a document, while still giving the system enough structure to behave reliably?
Turn this
to this
Turn this
to this
GETTING STARTED
I started by working with engineering and product to turn implementation logic into simple concepts a non-technical user could understand within the product.
Engineering Abstraction
Translated code concepts into product led agent building primitives in collaboration with engineers
NODES
PROMPT
TOOLS
Data connectors
IF\ELSE
EXTERNAL PROCEDURES
TERMINATE
Competitor Analysis
Studied other agent/workflow building products such as N8N, retool and Intercom on Mobbin
COMPETITOR ANALYSIS
great tool and branch visibility
Logic based
Graph first approach
Case studies
Say hello 👋
designedbyhari@gmail.com
© 2025 by Hariharan Ramesh
Never stop iterating