DEV Community: Gaurav Talesara

The Website Is No Longer the Center of Commerce

Gaurav Talesara — Wed, 02 Sep 2026 18:59:10 +0000

For years, digital commerce has been built around a simple assumption:

Get the user to the website.

Once the user arrives, guide them through a carefully designed journey.

Search.

Landing page.

Product page.

Cart.

Checkout.

The website was the center of the system.

But that assumption is starting to change.

AI-powered interfaces are creating a different model of interaction—one where users may discover products, evaluate options, and potentially complete transactions without following the traditional journey through a company's website.

The journey is becoming something closer to:

Intent → AI → Discovery → Decision → Transaction

The website may still exist.

It may still be important.

But it may no longer be the only interface between a business and its customers.

As an engineering leader, I find the architectural implications of this shift more interesting than the interface itself.

Because if AI becomes another layer between users and businesses, we need to ask a different question.

Instead of:

How do we build a better website?

We may need to start asking:

How does our product exist outside our website?

From page-centric products to capability-centric systems

Traditional web architecture is often built around pages.

A user visits a page.

The page loads data.

The user performs an action.

The backend processes that action.

The journey is designed around a human navigating an interface.

For example:

User
  ↓
Website
  ↓
Product Page
  ↓
Cart
  ↓
Checkout
  ↓
Transaction

The interface controls the experience.

But AI introduces another possibility.

User
  ↓
Intent
  ↓
AI Interface / Agent
  ↓
Business Systems
  ↓
Decision
  ↓
Transaction

This is a fundamentally different interaction model.

The AI does not necessarily need to understand how your website looks.

It needs to understand what your business can do.

What products do you offer?

What are the prices?

What is available?

What are the policies?

What actions can be performed?

What restrictions exist?

What systems can be accessed safely?

This moves part of the engineering problem away from pages and toward capabilities.

Your product needs to become understandable

Humans can navigate ambiguity.

They can look at a product page, interpret an image, read descriptions, compare options, and understand context.

Software systems cannot rely on that in the same way.

AI systems and agents need structured information.

If an external AI system needs to interact with your product, your underlying data becomes increasingly important.

For commerce, that could include:

Product information
Categories and attributes
Pricing
Availability
Inventory
Offers
Shipping information
Return policies
Product compatibility
Restrictions
Business rules

The quality of the user interface still matters.

But structured information behind the interface may become equally important.

A beautifully designed website is not enough if an external system cannot understand what the business actually offers.

APIs may become part of the product experience

For a long time, APIs were mostly considered technical infrastructure.

Something used by:

Mobile applications
Internal systems
Third-party integrations
Partner platforms

But as AI agents become more capable of interacting with external systems, APIs and system capabilities could increasingly become part of the product experience itself.

The question is no longer only:

Can our frontend perform this action?

It may become:

Can a trusted external system understand and safely perform this action?

For example:

Check availability
Get price
Apply offer
Create order
Calculate delivery
Process payment
Track order

These capabilities should not exist only inside tightly coupled frontend flows.

They need to be represented clearly within the system.

This does not mean every business suddenly needs a public API for everything.

Security, authentication, permissions, and business risk still matter.

But the architectural mindset is changing.

The system needs to expose capabilities in a way that can be understood and controlled.

The architecture behind AI commerce

A useful way to think about the future architecture is through four layers.

1. Interface Layer

This is where the user interacts.

It could be:

A website
A mobile app
Search
An AI assistant
A conversational interface
A voice interface
A third-party agent

The important point is that the business should not depend entirely on one interface.

Interfaces can change.

The core capabilities should remain stable.

2. Intelligence Layer

This layer understands intent.

For example:

"I need a laptop for software development under a certain budget."

The system needs to interpret:

User requirements
Budget
Product preferences
Constraints
Available options

An AI system may help translate human intent into structured actions.

But AI should not be responsible for inventing the truth.

It should retrieve information from reliable systems.

That distinction is important.

AI can interpret.

Your systems should remain the source of truth.

3. Business Capability Layer

This is where the actual business operations exist.

For example:

Product Catalog
Pricing Engine
Inventory System
Order Management
Payment System
Shipping System
Customer Management
Business Rules

This layer should contain the actual capabilities of the business.

The interface should consume these capabilities.

An AI agent may consume them too.

The website is just one consumer.

That is the architectural shift I find particularly interesting.

4. Trust and Control Layer

Once AI systems begin taking actions, trust becomes a core engineering problem.

An AI should not simply have unrestricted access to a system.

Businesses need to think about:

Authentication
Authorization
Permission boundaries
Transaction limits
Human confirmation
Audit trails
Observability
Error handling
Rollbacks
Fraud prevention

The more autonomous the system becomes, the more important these controls become.

AI agents may create a more flexible interface.

But flexibility without control creates risk.

The website becomes one interface among many

I don't think websites are disappearing.

People will continue using websites.

Brands will continue designing experiences.

Companies will continue optimize their products for humans.

But the website may gradually lose its position as the only center of the digital experience.

A product could increasingly exist across multiple interfaces.

                 Website
                    │
                    │
Search ─────── Business Systems ─────── Mobile App
                    │
                    │
               AI Agents
                    │
                    │
             Voice Interfaces

The business system becomes the foundation.

Interfaces become ways of accessing it.

This architecture is more resilient to changes in user behavior.

If a new interface becomes important, you don't need to rebuild the entire business.

You need to connect that interface to well-defined capabilities.

The engineering challenge is bigger than adding AI

This is why I don't think the right response is simply:

Let's add an AI chatbot.

The bigger opportunity is to look at the architecture underneath the product.

Can the system clearly represent the business?

Can capabilities be accessed independently?

Are APIs reliable?

Is product data structured?

Are business rules centralized?

Can actions be safely executed?

Can the system explain what happened?

Can failures be detected and recovered?

These are engineering questions.

And they will become increasingly important as AI moves from generating answers to coordinating actions.

The real competitive advantage may move deeper into the stack

For many years, companies competed heavily through the interface.

Better UX.

Better design.

Better onboarding.

Better conversion funnels.

Those things will remain important.

But AI-driven interfaces could make the underlying system architecture increasingly visible.

If an AI agent cannot understand your product, access reliable information, or interact safely with your capabilities, you may become harder to discover and transact with outside your own interface.

The competitive advantage may increasingly come from how well your business capabilities are represented inside the system.

Not just how good the website looks.

A question I think engineering teams should start asking

When building a new product, we often ask:

What screens do we need?

Maybe we should increasingly ask another question:

What capabilities does this business need to expose?

For example:

Instead of starting with:

Product Page
↓
Cart Page
↓
Checkout Page

Start by understanding:

Discover Product
Get Product Details
Check Availability
Calculate Price
Apply Offer
Create Order
Authorize Payment
Arrange Delivery
Track Order

Once the capabilities are clear, different interfaces can be built around them.

A website.

A mobile app.

An AI assistant.

A partner integration.

A voice interface.

The interfaces may change.

The business capabilities remain.

The interface is becoming more flexible. The system needs to become more structured.

That is the part of this shift that interests me most.

AI-powered commerce is not only a change in search, advertising, or checkout.

It could push engineering teams toward a different way of designing products.

One where products need to serve both:

Humans interacting through interfaces.

And increasingly:

AI systems acting on behalf of humans.

The website is not disappearing.

But it may become one interface among many.

And the businesses best positioned for that future may be the ones that have built systems with clear data, well-defined capabilities, strong controls, and reliable foundations.

The interface is becoming more flexible.

The system behind it needs to become more structured.

And I think that's going to be one of the most interesting engineering challenges of the next few years.

15 Things CA Firms Can Automate With AI — Starting With the Work Nobody Wants to Do

Gaurav Talesara — Fri, 28 Aug 2026 17:26:27 +0000

WhatsApp follow-ups, missing documents, GST workflows, loan cases, bank queries, fee collection and more.

A client sends a WhatsApp message:

“Sir, GST ka kya hua?”

Someone from the CA firm's team opens WhatsApp, searches for the client, checks an Excel sheet, looks through Google Drive, asks another team member, and finally replies.

The answer may take two minutes.

Finding the answer can take ten.

Now multiply that by hundreds of clients.

This is where I think the real opportunity for AI in CA firms begins.

Not with another chatbot.

With the repetitive work happening around the CA every single day.

AI Shouldn't Replace the CA. It Should Remove the Work Around the CA.

A CA's time is valuable.

Professional judgment, tax planning, financial advice, audits, client relationships and complex decisions require experience.

But many activities surrounding that work are repetitive.

Someone has to ask for documents.

Someone has to send reminders.

Someone has to check whether documents arrived.

Someone has to update an Excel sheet.

Someone has to follow up with a client.

Someone has to track a bank query.

Someone has to remember which loan case is waiting for what.

These are exactly the kinds of workflows where automation can help.

The question isn't:

“Where can we add AI?”

A better question is:

“What does the team repeatedly do every day that doesn't actually require professional judgment?”

Here are 15 areas worth exploring.

1. Client Document Collection

This is probably one of the easiest places to start.

CA firms constantly need documents from clients: bank statements, purchase registers, sales data, invoices, investment proofs, previous ITRs, GST information and more.

The difficult part isn't asking once.

It's keeping track of what's still missing across hundreds of clients.

Imagine:

Client: Patel Textiles

Required: 10 documents
Received: 8
Verified: 7
Missing: 2

An automation can send the request through WhatsApp or email.

When the client uploads a document, the system can identify it, attach it to the correct client, update the checklist and request whatever is still missing.

The staff no longer has to remember every outstanding document.

The system does.

2. AI Document Classification and Verification

Receiving a document is only half the problem.

The next question is:

Did the client send the right document?

AI can classify uploaded files and perform basic checks before they reach the CA team.

For example:

Uploaded: bank_statement_august.pdf

Document type: Bank Statement
Client: Patel Textiles
Period: August
Readable: Yes
Status: Verified

Or:

Expected: Bank Statement

Received: Invoice

Status: Wrong Document
Action: Request correct document

This can save staff from manually opening and sorting hundreds of files.

3. WhatsApp Client Query Automation

WhatsApp has become one of the most important communication channels for many Indian businesses.

CA firms receive questions throughout the day:

“What documents do I need?”

“When is the GST deadline?”

“Did you receive my statement?”

“What is pending from my side?”

“Has my return been filed?”

An AI assistant can handle the first level of these questions.

But there is an important difference between a generic chatbot and a useful CA assistant.

A generic chatbot knows what GST is.

A useful assistant knows that this particular client's GST filing is waiting for two documents.

Context is the real value.

4. Client Onboarding

New clients create a surprising amount of administrative work.

A new client may require:

KYC.

PAN.

GST details.

Previous returns.

Accounting data.

Bank statements.

Engagement documentation.

Service selection.

Team assignment.

Instead of managing this through spreadsheets and messages, an onboarding workflow can track everything.

Client Onboarding: 72%

Completed:
KYC
PAN
GST

Pending:
Previous ITR
Bank Statements
Accounting Data

The client sees what is pending.

The staff sees what is incomplete.

The partner sees the overall status.

5. GST Compliance Readiness

Compliance automation shouldn't stop at sending deadline reminders.

Knowing that a GST return is due in five days is useful.

Knowing why the return isn't ready is much more useful.

For example:

GSTR-3B

Sales Data        Complete
Purchase Data     Complete
GSTR-2B           Complete
Reconciliation    3 Exceptions
CA Review         Pending
Client Approval   Pending

Now the system can identify exactly what is blocking the filing.

That turns a simple reminder system into a workflow system.

6. GST Reconciliation and Exception Detection

AI doesn't need to review everything.

Sometimes its most valuable role is to find the things that deserve human attention.

For example:

Duplicate invoices
GST amount mismatches
Purchase invoices missing from 2B
Unusual ITC movements
Sales data mismatches
Unexpected changes in margins
Credit-note anomalies

Instead of asking someone to manually inspect everything, AI can create an exception list.

The CA reviews the exceptions.

This is a powerful pattern for professional services:

AI prepares and prioritizes. Humans review and approve.

7. ITR Document and Information Collection

ITR preparation involves another predictable collection process.

The firm may need Form 16, capital gains information, investment proofs, bank statements, interest certificates, previous returns and other supporting information.

The workflow can become:

ITR Client
↓
Checklist Generated
↓
Documents Requested
↓
Documents Received
↓
AI Classification
↓
Missing Information Identified
↓
Staff Review
↓
CA Review

The system isn't preparing tax advice on its own.

It's reducing the administrative work required to get the case ready.

8. Compliance Deadline Management

A calendar tells you when something is due.

A workflow tells you whether you're actually ready.

A better compliance system can automatically create tasks based on the client's services.

For example:

Client
↓
GST
↓
TDS
↓
ITR
↓
ROC
↓
Audit

Each service creates its own workflow.

Tasks can be assigned to staff.

Missing information can trigger client reminders.

Unresolved items can be escalated.

The partner gets visibility without having to ask every employee for an update.

9. Internal Task Assignment

One of the biggest problems in a growing CA firm is simply knowing:

Who is doing what?

A compliance workflow could automatically create:

Client: ABC Industries

Task: GST Reconciliation
Owner: Rahul
Due: 25 August
Status: Waiting for Client

Once the documents arrive:

Status: Ready for Review

Once the CA approves:

Status: Completed

This creates a clear operational trail.

It also makes workload visible across the team.

10. Fee and Payment Follow-ups

Another repetitive process is collecting fees.

The basic workflow is simple:

Invoice
↓
Due Date
↓
Reminder
↓
Client Response
↓
Payment
↓
Receipt

But automation can make this smarter.

If a client says:

“I'll pay on Friday.”

The system can record the commitment.

If Friday passes and payment hasn't arrived, the follow-up can happen automatically.

Staff only needs to intervene when the normal workflow doesn't work.

11. Loan Lead Qualification

This is where things get particularly interesting.

Many CA firms also have finance or loan departments.

They may help clients with business loans, working capital, project finance, machinery finance, home loans, vehicle loans and other financing requirements.

A client might simply send:

“Mare ₹2 crore ni working capital joiye che.”

Instead of immediately handing the conversation to someone, an AI assistant can collect the basic information required for an initial assessment.

For example:

Business Type
Annual Turnover
Existing Loans
Current Bank
GST Status
ITR History
Loan Requirement
Purpose
Collateral

The result becomes a structured finance lead instead of an unstructured WhatsApp conversation.

12. Loan Document Collection

Loan processing involves a significant amount of documentation.

Depending on the case, the team may need financial statements, ITRs, GST information, bank statements, existing loan details, KYC, property documents and other lender-specific information.

A Loan Desk can show:

Loan Case #1047

Required: 24
Received: 18
Verified: 14
Missing: 6

The system can automatically follow up with the client.

It can also identify which cases are blocked because of missing information.

That makes the finance team's pipeline much easier to manage.

13. Bank Query Tracking

This is one of the most interesting workflows in loan processing.

A bank might ask:

“Please explain the increase in debtor days.”

Then:

“Please provide updated CMA.”

Then:

“Please submit promoter ITR.”

These requests can arrive through email, WhatsApp or phone calls.

A structured Loan Desk could turn each request into a task.

Loan Case #1047

Bank Query:
Explain increase in debtor days

Owner:
Rahul

Status:
Waiting for Client

Due:
Tomorrow

Required:
Debtor Ageing Report

Now the team knows exactly what is pending and who owns it.

14. AI-Assisted CMA and Financial Analysis

For CA firms involved in project finance and business loans, financial analysis can become another area for automation.

A system could take historical financial information and help prepare a first-pass analysis.

Historical Financials
↓
P&L
Balance Sheet
Cash Flow
↓
Financial Ratios
↓
Projected Financials
↓
CMA / Project Analysis
↓
CA Review

AI could also help identify unusual changes or prepare explanations for financial movements.

But the final assumptions, analysis and professional output should remain under human review.

AI should accelerate the preparation.

It shouldn't blindly make the decision.

15. An AI Daily Brief for the CA Partner

Eventually, all of these workflows can come together.

But I don't think the answer is another dashboard filled with charts.

A CA partner doesn't necessarily need more information.

They need to know:

What needs my attention today?

The system could provide a simple daily summary:

7 filings blocked
5 clients haven't submitted documents
3 bank queries pending
₹12.8L overdue
8 loan cases waiting for action

That's more useful than opening five different spreadsheets and asking five different people for updates.

The goal isn't more information.

It's less cognitive load.

Don't Build Everything at Once

This is probably the most important point.

It is tempting to build a complete CA platform with:

CRM.

WhatsApp.

AI chatbot.

GST.

ITR.

Documents.

Loans.

CMA.

Payments.

Analytics.

That can quickly turn into a six-month or one-year project before anyone knows whether the product solves a real problem.

A better approach is to pick one workflow.

For example:

Document Collection
↓
Document Verification
↓
Compliance Workflow
↓
GST Exceptions
↓
Loan Desk
↓
Financial Intelligence

Each module can solve a real problem independently.

Then they can gradually connect.

What Should Actually Be Automated?

A simple rule can help.

Automate work that is:

Repetitive
High-volume
Time-consuming
Rule-based
Easy to verify

Keep humans in control of:

Professional judgment
Tax positions
Financial decisions
Client advice
Final approvals
Lending decisions

The best AI system isn't the one that makes every decision.

It's the one that handles the repetitive work and brings the important exceptions to the professional.

The Bigger Opportunity

The future of CA-firm software probably isn't another chatbot.

It's a system that understands the state of every client and every workflow.

Which documents are missing?

Which filings are blocked?

Which tasks are overdue?

Which loan cases are waiting for the bank?

Which clients haven't paid?

Which cases need the CA's attention?

And which tasks can simply be handled automatically?

The CA remains the expert.

The team remains responsible for professional execution.

AI becomes the operational layer that connects the work.

That's where I think the opportunity becomes much more interesting.

If you run a CA firm, what is the one repetitive process your team does every day that you would happily never have to manage manually again?

NOOA: What If an AI Agent Was Just a Python Object?

Gaurav Talesara — Wed, 12 Aug 2026 17:32:29 +0000

There is something interesting happening in the AI agent space.

We have spent the last couple of years building agents using prompts, tools, function calling, workflows, graphs, memory systems, orchestration layers, and increasingly complicated frameworks.

And now NVIDIA Labs has released something that made me stop and think:

What if an AI agent was just a Python object?

That is the basic idea behind NOOA — NVIDIA Object-Oriented Agents.

It is an open-source, model-agnostic Python framework that represents an agent as a Python class, where the object's fields represent state, methods represent capabilities, docstrings can define instructions, and type annotations define interfaces.

The project is still very new and explicitly described as research software. But I think the idea behind it is worth paying attention to.

NOOA on GitHub

So, what is actually different?

Let's look at the traditional way we might build an agent.

We could have:

A system prompt
A collection of tools
Tool schemas
A memory component
An orchestration loop
State management
Some workflow engine
Observability/tracing
Retry logic
Structured output handling

All of these pieces are useful.

But they also create a growing abstraction layer between the developer and the agent.

NOOA takes a different approach.

You define something like:

from nooa import Agent

class SupportAgent(Agent):
    """You are a customer support agent."""

    order_db: OrderDB

    def is_refund_eligible(self, order: Order) -> bool:
        return (
            order.delivered
            and order.days_since_delivery <= 30
        )

    async def triage(
        self,
        message: str,
        order: Order
    ) -> Ticket:
        """Create a typed support ticket."""
        ...

And suddenly the architecture feels very familiar.

The agent is an object.

Its state is on the object.

Its capabilities are methods.

Its interfaces are typed.

Its instructions can live with the methods.

And the interesting part is the ....

A method with a real Python implementation behaves like normal deterministic Python.

A method with an ... body becomes an LLM-driven method at runtime.

That is a surprisingly simple idea.

Why does this matter?

The thing that caught my attention isn't just the syntax.

It is the mental model.

We have traditionally thought about an AI agent as:

Prompt + Model + Tools + Memory + Loop

NOOA is suggesting another abstraction:

Agent = Software Object + Model

That is a meaningful shift.

If the agent is a Python object, then many things software engineers already know how to do become natural again.

Testing.

Refactoring.

Version control.

Tracing.

Dependency injection.

Type checking.

Composition.

State management.

Code review.

Instead of learning another workflow DSL or another orchestration abstraction, developers can start with something they already understand: Python.

NVIDIA's implementation goes further than simply wrapping an LLM in a class. The framework supports typed I/O, live Python objects passed by reference, model-generated Python as an action mechanism, programmable agent loops, context/event APIs, tracing, and long-term memory.

The part I find especially interesting: code as action

This is probably one of the most interesting pieces of NOOA.

Instead of every capability necessarily becoming a traditional function/tool schema that gets serialized into the model context, the model can generate Python and operate within the agent's environment.

In other words:

The model doesn't only call tools.
The model can write code to use the agent's capabilities.

That changes the interface between the LLM and the application.

Python methods and type annotations can become the interface the model works with.

For developers, this could eventually mean less time maintaining huge collections of tool definitions and more time defining clean software interfaces.

Of course, this also creates a very important security problem.

If an LLM can generate and execute Python, we should treat that code as untrusted.

NOOA's own documentation is very clear about this: its AST validation and module restrictions are defense-in-depth mechanisms, not a security boundary. The recommended containment boundary is OS-level sandboxing such as containers or NVIDIA OpenShell.

And I think that distinction is extremely important.

Another interesting idea: agent state

There is another architectural question that NOOA makes interesting.

Where should an agent's state live?

Today, a lot of agent state effectively lives inside the context window.

The longer the conversation becomes, the more we start thinking about:

summarization
context compression
retrieval
memory
token optimization

NOOA instead treats the agent as an object with state.

That opens the door to a different model:

Agent
 ├── State
 ├── Capabilities
 ├── Memory
 ├── Methods
 ├── Context
 └── Model

The LLM becomes part of the object rather than the object being constructed around an LLM conversation.

That is subtle, but I think it could become important as agents become more persistent and autonomous.

Is NOOA going to replace other agent frameworks?

I don't think we know that yet.

And I would actually argue that this is the wrong question.

NOOA is currently a 0.x research preview, and NVIDIA says its public API is not yet stable and can change between releases.

So I wouldn't recommend looking at it today and saying:

"This is the new standard for AI agents."

It isn't.

But I would definitely recommend watching it.

Because research projects like this sometimes introduce an abstraction that looks unusual initially and becomes obvious later.

Remember how strange some ideas looked before they became standard programming patterns?

The interesting question here is whether object-oriented programming becomes a useful abstraction for agent engineering.

My prediction

I don't think the future will be one giant agent framework.

I think we are going to see a convergence of several ideas.

Agents will increasingly look like software components rather than chatbot conversations.

They will have:

Persistent state
Typed interfaces
Memory
Capabilities
Deterministic code
Model-driven reasoning
Observability
Sandboxed execution
Testable behavior
Composable sub-agents

And the boundary between "AI logic" and "software logic" will become much thinner.

That's what makes NOOA interesting to me.

It isn't necessarily introducing another way to call an LLM.

It is asking a more fundamental question:

What should an AI agent look like from a software engineer's perspective?

And the answer from NVIDIA Labs is:

Maybe it should just look like a Python object.

What I want to see next

This is where things get really interesting.

I'd love to see how this approach evolves around:

1. Production reliability

How do these agents behave under real workloads, failures, retries, concurrency, and partial state?

2. Security

If agents can generate and execute code, sandboxing will become a fundamental part of the architecture, not an optional feature.

3. Multi-agent systems

What happens when Python objects representing agents start collaborating with each other?

ResearchAgent
       ↓
PlanningAgent
       ↓
CodingAgent
       ↓
ReviewAgent
       ↓
DeploymentAgent

Can these simply become composable software objects?

4. Agent testing

This could be particularly powerful.

Imagine being able to test an agent almost like any other Python component:

def test_refund_policy():
    agent = SupportAgent(...)
    assert agent.is_refund_eligible(order) is True

And then separately evaluate the probabilistic behavior of its LLM-driven methods.

That separation between deterministic logic and model-driven behavior could become a very useful engineering pattern.

5. Agent observability

NOOA already traces LLM calls, code execution, and method invocations.

I think this will become critical.

As agents become more autonomous, "the model said something weird" won't be enough for debugging.

We will need to know:

What did the agent know?
What state did it have?
What method did it invoke?
What code did it generate?
What did that code change?
What model decision happened?
What happened next?

That is software observability applied to probabilistic systems.

The bigger shift

Maybe the most interesting thing about NOOA isn't NOOA itself.

Maybe it is the direction it represents.

The first generation of AI applications taught us how to integrate models into software.

The next generation is teaching us how to make models behave like software components.

And eventually, I think we will stop drawing such a sharp line between the two.

An agent won't just be:

"an LLM with some tools."

It may become:

"a software component whose reasoning happens to be powered by a model."

NOOA is still early.

The APIs will change.

The patterns will evolve.

There will be competing approaches.

Some ideas will work. Some won't.

But that's exactly why I think it is worth experimenting with now.

Not because NOOA is already the answer.

But because it might be pointing toward a different question.

What does software engineering look like when the software itself can reason?

That is the part I'm watching.

And I have a feeling we are going to see some very interesting updates in this space over the next year.

If you're building AI agents today, I'm curious:

Would you rather build your next agent as a workflow/graph — or as a Python object?

I'd love to hear what other engineers think.

AI #AIAgents #AgenticAI #NVIDIA #Python #LLM #GenerativeAI #SoftwareEngineering #ArtificialIntelligence #DeveloperExperience

Building an AI Workforce for Insurance with n8n, OpenAI, LangGraph and Supabase

Gaurav Talesara — Tue, 16 Jun 2026 18:59:15 +0000

AI for Preparation. Humans for Judgment.

Most AI projects today are one of these:

A chatbot
A customer support bot
A voice assistant
A Q&A system

But I wanted to explore something bigger:

What if businesses could build an AI Workforce?

Instead of one AI assistant,

imagine:

Customer

↓

AI Workforce

├── Discovery Agent

├── Research Agent

├── Policy Comparison Agent

├── Recommendation Agent

├── CRM Agent

└── Follow-up Agent

↓

Human Advisor

↓

Customer

This article explains the architecture and design decisions behind such a system.

Why Insurance?

Insurance is an interesting industry for AI.

Because:

Research is repetitive.
Recommendations are data-driven.
Follow-ups are expensive.
Trust is critical.
Human judgment is still necessary.

This makes Insurance a perfect Human-in-the-Loop AI use case.

Human In The Loop

This is the core philosophy.

I don't want AI to automatically sell insurance.

I don't want AI replacing advisors.

I want:

AI prepares.

Humans decide.

The workflow becomes:

Customer

↓

AI Workforce

↓

Human Advisor Review

↓

Customer

This creates:

Faster recommendations
Better customer experience
Safer AI adoption
Human accountability

AI Workforce Architecture

Customer

↓

WhatsApp
Phone Call
Website Chat
Email

↓

AI Workforce

├── Discovery Agent

├── Research Agent

├── Comparison Agent

├── Recommendation Agent

├── CRM Agent

└── Follow-up Agent

↓

Human Advisor

↓

Customer

Discovery Agent

The Discovery Agent understands the customer.

Responsibilities:

Collect customer profile
Understand goals
Assess risk
Understand existing insurance
Identify gaps

Example Output:

{
  "risk_level":"medium",
  "family_type":"married_with_children",
  "insurance_goal":"health_and_term",
  "recommended_health_cover":"20L",
  "recommended_term_cover":"3Cr"
}

Research Agent

The Research Agent acts like an insurance analyst.

Responsibilities:

Analyze policies
Compare waiting periods
Review exclusions
Evaluate premiums
Generate recommendations

Example:

{
  "customer_profile_summary":"...",
  "top_recommendations":[
      "...",
      "...",
      "..."
  ],
  "risks":[
      "...",
      "..."
  ],
  "confidence_score":0.92
}

Comparison Agent

Creates structured comparisons:

Feature	Plan A	Plan B	Plan C
Coverage	✓	✓	✓
Premium	✓	✓	✓
Waiting Period	✓	✓	✓
Claim Process	✓	✓	✓

Output:

Best Overall
Best Budget
Best Family Plan

Recommendation Agent

Creates:

Customer Summary
Recommended Plan
Alternatives
Risk Analysis
Advisor Notes

Everything before the advisor joins.

CRM Agent

Updates:

Customer Records
Recommendations
Activities
Opportunity Status
Tasks

Follow-up Agent

Handles:

WhatsApp reminders
Renewal alerts
Email follow-ups
Call notes
Engagement tracking

Omnichannel AI

One important decision:

Customers should not install a new application.

The AI Workforce should operate through:

WhatsApp
Phone Calls
Website Chat
Email
SMS

Different channels.

Same intelligence.

Technology Stack

Frontend

Next.js
Tailwind
Lovable AI

Workflow Layer

AI Models

OpenAI
Gemini
Claude

Multi-Agent Framework

LangGraph

Database

Supabase
PostgreSQL

Memory

Pinecone

Monitoring

LangSmith
PostHog

Why n8n First?

I intentionally started with n8n.

Because:

Fast prototyping
Visual workflows
Easy OpenAI integration
Easy Supabase integration
Easy WhatsApp integration
Easy Email workflows

After validation:

n8n

↓

NestJS

↓

LangGraph

↓

Production AI Workforce

The Bigger Vision

I don't think AI will replace Insurance Advisors.

I think every advisor may eventually have:

An AI Workforce working behind the scenes.

AI provides:

Speed
Consistency
Scale

Humans provide:

Trust
Empathy
Judgment

The future is not:

Human vs AI

The future is:

Human + AI Workforce

If you're building something similar, I'd love to hear your thoughts.

The Rise of Production-Grade AI Infrastructure

Gaurav Talesara — Sat, 23 May 2026 07:01:21 +0000

Most AI products today are impressive in demos.

But the moment they hit production:

workflows break
context fails
hallucinations appear
costs explode
observability disappears

The AI industry does not really have an “intelligence” problem anymore.

It has an infrastructure problem.

For the last two years, the ecosystem focused heavily on:

chat interfaces
prompt engineering
copilots
wrappers around foundation models
“AI-powered” product features

That phase accelerated adoption.

But the market is now entering a different stage.

The hard problem is no longer:

“Can AI generate something useful?”

The hard problem is:

“Can AI systems operate reliably in real production environments?”

And that is where the next major opportunity is emerging.

The Demo Problem

Most AI demos look incredible.

They can:

generate code
summarize documents
automate workflows
answer questions
orchestrate tasks

But production environments expose a completely different reality.

Once real users, real workflows, and real operational constraints enter the system, problems begin to appear:

hallucinations
fragile context handling
inconsistent outputs
broken execution chains
runaway costs
poor observability
unsafe automation
missing governance
unpredictable agent behavior

This is why so many AI pilots never move beyond experimentation.

The market today is filled with:

AI interfaces
AI assistants
AI wrappers
AI copilots

But what enterprises actually need are:

reliable systems
operational controls
execution runtimes
observability layers
governance infrastructure
context orchestration

That is the real bottleneck now.

AI Systems Need a New Production Stack

Traditional software engineering was built around deterministic systems.

AI systems are different.

They are:

probabilistic
context-sensitive
state-fragile
operationally unpredictable

That means traditional software patterns are no longer enough.

AI requires an entirely new operational layer.

This feels very similar to earlier infrastructure shifts:

Kubernetes standardized container orchestration
Datadog transformed observability
Stripe simplified payment infrastructure
Temporal improved workflow reliability

AI is now reaching a similar stage.

The next generation of products will not just be AI applications.

They will be:

AI production infrastructure platforms.

The Real Layers of a Production-Grade AI System

Most discussions about AI still focus only on models.

But production-grade AI systems require much more than a model.

Below are the infrastructure layers that are becoming increasingly important.

1. Context Engineering

This is becoming one of the most critical areas in AI engineering.

Most AI systems fail not because the model is weak, but because the context is poor.

Production systems need to manage:

historical memory
workflow state
user intent
permissions
business logic
external data
codebase understanding
semantic relationships

This goes far beyond basic RAG.

The future belongs to systems that can dynamically assemble the right context at the right moment.

Prompt engineering is becoming commoditized.

Context engineering is becoming the moat.

2. Agent Execution Runtime

Most AI agents today are unreliable because they lack execution infrastructure.

A production runtime needs:

retries
rollback support
checkpoints
workflow state tracking
timeout handling
safe execution paths
human approval systems

Without this, AI workflows become fragile very quickly.

The market does not just need agents.

It needs:

workflow infrastructure for AI systems.

3. Observability for AI Systems

Debugging traditional software is already difficult.

Debugging AI systems is significantly harder.

Production AI requires visibility into:

prompts
memory retrieval
tool calls
reasoning chains
execution paths
token usage
latency
hallucination patterns
workflow failures

Most current systems still operate like black boxes.

This creates a massive opportunity for:

AI observability
AgentOps
runtime tracing
execution replay
quality monitoring

The industry will likely see a:

“Datadog for AI systems”

category emerge.

4. Governance and Safety

As AI systems become more autonomous, governance becomes mandatory.

Enterprises need:

approval workflows
audit trails
permission systems
policy enforcement
data isolation
secure execution environments

Without operational controls, companies will struggle to trust autonomous systems at scale.

This becomes especially important in:

healthcare
finance
enterprise automation
internal copilots
operational workflows

Governance is no longer optional infrastructure.

It is foundational infrastructure.

5. Evaluation and Reliability Testing

One of the biggest problems in AI today is silent degradation.

An AI workflow may work perfectly today and fail tomorrow because of:

model updates
prompt changes
retrieval drift
API schema changes
edge cases
workflow changes

That means AI systems need continuous evaluation.

Production-grade AI requires:

regression testing
scenario simulation
adversarial testing
replay systems
benchmark scoring
workflow validation

This category is still massively underdeveloped.

Why Infrastructure Will Matter More Than Interfaces

The first AI wave rewarded:

interfaces
demos
speed
accessibility

The next AI wave will reward:

reliability
orchestration
observability
governance
scalability
operational maturity

That changes where the real value gets created.

The winning companies may not be the ones with the best chat interface.

They may be the ones building:

context runtimes
orchestration layers
observability platforms
execution infrastructure
repo intelligence systems
AI governance tooling

The real opportunity is shifting downward into the infrastructure layer.

Repo Intelligence Might Become a Major Category

One particularly interesting opportunity is repo intelligence.

Current AI coding tools can generate code.

But they often lack:

architectural understanding
dependency awareness
service relationships
domain knowledge
operational context

That creates problems in large production codebases.

A smarter system would:

scan repositories
understand architecture
build dependency graphs
map services
infer business domains
track workflows
generate contextual intelligence for AI systems

This could dramatically improve:

AI coding reliability
automated refactoring
debugging
onboarding
workflow automation

The future of AI-assisted engineering may depend heavily on systems that deeply understand software architecture.

What This Means for Builders

If you are building in AI today, this shift matters.

The market is getting saturated with:

wrappers
chat interfaces
generic copilots
shallow automation tools

But infrastructure gaps are still massively underbuilt.

That means opportunities are emerging in:

context orchestration
observability
evaluation systems
governance tooling
repo intelligence
workflow runtimes
execution reliability

The next major AI products may come from engineering pain, not prompt creativity.

The Market Is Moving from Apps to Systems

This is the transition happening right now.

We are moving from:

AI apps → AI infrastructure
prompts → context systems
copilots → execution runtimes
experimentation → operational maturity
wrappers → production platforms

The companies that win in AI will likely be the ones that solve:

reliability
orchestration
observability
governance
context management
execution safety

Not just generation.

The biggest AI companies of the next decade may not even look like AI companies.

They may look like infrastructure companies.

Final Thoughts

AI will absolutely transform software.

But models alone are not enough.

The next major challenge is building systems that AI can operate inside reliably.

That means:

better infrastructure
better orchestration
better context systems
better observability
better governance
better operational tooling

The future of AI does not belong only to model providers.

It also belongs to the companies building the operational layer around those models.

And that may become one of the biggest infrastructure opportunities of the next decade.

Why Software Isn’t Built for AI Agents

Gaurav Talesara — Sat, 02 May 2026 12:52:03 +0000

The next users of your software won’t be humans.
They’ll be agents.

And most software today is completely unprepared for that.

Right now, AI agents are:

Browsing websites
Filling forms
Clicking buttons
Navigating dashboards

That’s not scale. That’s a workaround.

We’re forcing machines to behave like humans—because our systems were never designed for anything else.

The Core Problem

Modern software is built around a simple assumption:

A human will be sitting in front of a screen.

That assumption drives everything:

UI-heavy workflows
Step-by-step interactions
Documentation meant to be read, not executed

But agents don’t need interfaces.
They need interfaces they can reason about and execute against programmatically.

Where Current Systems Break for Agents

Let’s break this down from a systems perspective.

1. UI-First Architecture

Most SaaS products expose functionality through:

Dashboards
Forms
Buttons

Agents interacting with these:

Rely on scraping or automation layers
Break when UI changes
Lack reliability

2. Non-Deterministic Outputs

Agents need:

Structured responses
Predictable schemas

Instead, they get:

HTML pages
Inconsistent API responses
Unstructured data

3. Human-Centric Authentication

Current flows:

OAuth screens
Email verification
CAPTCHA

These are friction points for agents trying to:

Discover tools
Authenticate
Execute tasks autonomously

4. Documentation Isn’t Machine-Readable

Docs today are:

Written for humans
Scattered across pages
Hard to parse programmatically

Agents need:

Structured capability descriptions
Executable contracts
Clear input/output expectations

APIs Alone Are Not the Answer

A common assumption is:

“We already have APIs, so we’re agent-ready.”

That’s not true.

APIs are:

Too generic
Often inconsistent
Not designed for autonomous decision-making

Agents need more than endpoints.

They need:

Action schemas (what can be done, not just how)
Deterministic contracts (guaranteed outputs)
Capability discovery (what tools exist and when to use them)

What “Agent-First Software” Actually Looks Like

If we design systems for agents as first-class users, the architecture changes.

1. Machine-Readable Interfaces

Instead of UI-first:

Structured APIs with strict schemas
Tool definitions with clear contracts
Standardized input/output formats

2. Programmatic Onboarding

Instead of:

Signup → verify → explore

Agents should:

Discover → authenticate → execute

This requires:

Auto-provisioned credentials
Machine-readable pricing/limits
Capability endpoints

3. Permissioned Execution

Agents need controlled autonomy:

Scoped access tokens
Role-based permissions
Execution boundaries

4. Deterministic Execution Layer

Every action should be:

Predictable
Retry-safe
Observable

5. Observability for Agents

Traditional logs aren’t enough.

We need:

Decision tracing
Tool-call lineage
Cost per execution
Latency breakdowns

A Practical Agent-System Architecture

A simplified flow looks like this:

Agent
  ↓
Planner (decides what to do)
  ↓
Tool Registry (what tools are available)
  ↓
Execution Layer (calls APIs/tools)
  ↓
Response Validator (ensures correctness)
  ↓
Memory (stores context + learnings)

Each layer is critical:

Planner → reasoning
Tool registry → discoverability
Execution → action
Validator → reliability
Memory → continuity

This is very different from traditional request-response systems.

Where the Opportunity Is

Most people today are focused on:

“How do we build better agents?”

But the bigger opportunity is:

“How do we build better systems for agents to operate on?”

Every major category is open:

CRM → agent-native workflows
Payments → programmable financial actions
Support → autonomous resolution systems
Analytics → queryable, structured insights

Not as add-ons.
But as core design principles.

What Most People Get Wrong

❌ “APIs are enough”

They’re not.
Agents need structured, reliable, discoverable systems.

❌ “Just add AI on top”

That creates brittle layers, not scalable systems.

❌ “Agents will replace software”

No.
Agents will consume software differently.

The Shift That’s Coming

We’re moving from:

Human-first software → to
Agent-first systems

This isn’t a feature upgrade.

It’s a paradigm shift in how software is designed and consumed.

Final Thought

The companies that win won’t be the ones with the smartest agents.

They’ll be the ones:

Agents prefer to use.

👋 If You’re Building in This Space

I’m currently working on:

Agent-based systems
Automation architectures
AI-native SaaS workflows

If you’re exploring similar problems or thinking about building agent-first products, I’d be interested to exchange ideas.

Engineers Won’t Just Have Salaries - They’ll Have Token Budgets

Gaurav Talesara — Mon, 13 Apr 2026 18:40:27 +0000

Introduction

There’s a subtle shift happening in how software is being built.

It’s not loud.
It’s not fully standardized.
But it’s already visible if you look closely.

We are moving from a world where:

Engineering output was limited by human effort

To a world where:

Output is increasingly limited by how much AI you can effectively use

And that introduces a new concept most teams are not yet fully prepared for:

Token budgets.

What’s Changing Right Now

If you zoom into how modern engineering teams are working:

AI tools are no longer optional — they’re embedded in daily workflows
Engineers are generating, reviewing, and iterating faster than ever
The bottleneck is shifting from writing code to orchestrating systems

Some early signals:

Companies are beginning to track AI usage per employee
AI costs are becoming a visible line item in engineering budgets
Token consumption is growing at an unpredictable pace

This isn’t theoretical.

It’s already happening in pockets of the industry.

The Real Constraint Has Changed

Traditionally, engineering constraints looked like this:

Developer bandwidth
System architecture
Infrastructure scaling

Now there’s a new constraint emerging:

Effective AI utilization

Two engineers today are no longer equal if:

One uses AI occasionally
The other builds workflows, agents, and automation around it

The second engineer is operating with leverage.

And that leverage is powered by tokens.

Why Token Budgets Will Emerge

Right now, most companies are in an experimental phase:

Pay-as-you-go AI usage
No clear limits
Costs that are hard to predict

This doesn’t scale.

As usage increases, companies will need:

Cost control
Predictability
Fair distribution of resources

The natural evolution?

Allocated token budgets per engineer or team

Just like:

Cloud budgets
API rate limits
SaaS seat allocations

Tokens = The New Productivity Unit

We’re used to measuring productivity through:

Output (features shipped)
Velocity (story points, sprints)
Efficiency (time to deliver)

But AI introduces a different layer.

Now, productivity is increasingly tied to:

How effectively you can convert tokens into outcomes

Not all token usage is equal.

Some engineers waste tokens on low-value prompts
Others build reusable systems that compound output

This is where the real differentiation will happen.

The Rise of the “AI-Orchestrating Engineer”

The best engineers in the next phase won’t just:

Write clean code
Design scalable systems

They will:

Design agent workflows
Optimize token usage vs output
Build systems that act, not just respond

In other words:

They will orchestrate intelligence.

What This Means for Engineering Leaders

If you’re leading teams today, this shift has implications:

1. Budgeting will change

AI costs will move from “tools” to core infrastructure spend

2. Hiring signals will change

You won’t just evaluate:

Coding ability

You’ll evaluate:

AI leverage
System thinking
Automation mindset

3. Internal tooling will evolve

Teams will build:

Internal agents
Workflow automation systems
Token-efficient pipelines

Why This Isn’t Mainstream Yet

It’s important to stay grounded.

Most companies today:

Do NOT have formal token budgets
Are still figuring out pricing and limits
Are experimenting without clear governance

This is still early-stage behavior.

But the direction is clear.

The Bigger Shift: From Software to Systems

Today’s companies are built on:

APIs
Databases
Services

Tomorrow’s companies will increasingly rely on:

Agents
Workflows
Token pipelines

And that changes how value is created.

Final Thought

We’re not just adding AI to existing systems.

We’re redefining how work gets done.

The question is no longer:

“How fast can your team build?”

It’s:

“How effectively can your team deploy intelligence?”

And in that world—

Tokens become leverage.

Closing

This shift isn’t fully visible yet.

But it’s already in motion.

The teams that understand it early will have an advantage that compounds over time.

If you're building or leading engineering teams right now—

How are you thinking about AI usage?

As a tool…

Or as infrastructure?

Before You Deploy AI-Generated Code: A Production Checklist

Gaurav Talesara — Sat, 14 Mar 2026 05:29:49 +0000

AI can generate working code in seconds. Tools like ChatGPT, Claude, and GitHub Copilot have dramatically accelerated development.

But generating code is not the same as shipping production-ready software.

AI-generated code often introduces hidden issues: outdated dependencies, inefficient logic, security risks, and architecture problems. Before deploying AI-generated code to production, engineers should review it carefully.

This article outlines a practical checklist to validate AI-generated code before moving it to production.

1. Dependency and Package Validation

AI frequently suggests libraries without verifying their current status. Some packages may be deprecated, insecure, or poorly maintained.

Before deploying, validate all dependencies.

Things to check:

Verify package versions
Ensure packages are actively maintained
Lock dependency versions
Remove unnecessary libraries

Useful commands for Node.js projects:

npm audit
npm outdated

Tools that help with dependency validation:

Snyk
Dependabot
OWASP Dependency Check

These tools can detect vulnerable dependencies and recommend secure versions.

2. Vulnerability and CVE Scan

Many open-source libraries contain known vulnerabilities. AI-generated code may unknowingly include these dependencies.

Before production deployment, perform a vulnerability scan.

Things to check:

Known CVEs in dependencies
High or critical severity vulnerabilities
Security advisories from package maintainers

Recommended tools:

Snyk
Trivy
OWASP Dependency Check

Address critical vulnerabilities before moving forward.

3. Check for Broken Code

AI-generated code may appear correct but fail in real scenarios.

Common problems include:

Missing imports
Incorrect API usage
Poor edge case handling
Null or undefined errors

Static analysis tools can help detect these issues early.

Useful tools:

ESLint
TypeScript type checking
Static code analyzers

Example:

npm run lint
tsc --noEmit

These checks ensure the codebase is structurally sound.

4. Performance Review

AI-generated code may not always be optimized. In many cases, it produces inefficient queries or unnecessary loops.

Common performance issues include:

N+1 database queries
Repeated API calls
Large unpaginated responses
Inefficient loops

Example of inefficient logic:

for (const user of users) {
  await db.getOrders(user.id);
}

Improved approach:

await db.getOrdersForUsers(userIds);

Optimizing performance early prevents scaling issues later.

5. Scalability Validation

Code that works locally may fail under production load. AI-generated code often lacks scalability considerations.

Key things to verify:

Stateless architecture
Proper database indexing
Rate limiting for APIs
Background job processing for heavy tasks

For Node.js systems, queues are often used to handle asynchronous workloads.

Common tools include:

Redis
BullMQ
RabbitMQ

This ensures that the system can handle increased traffic and workload.

6. Reliability and Error Handling

Production systems must handle failures gracefully.

AI-generated code may miss important reliability patterns such as retries or proper error handling.

Important checks include:

Proper try-catch blocks
Retry mechanisms for external services
Circuit breakers
Graceful fallback responses

Example:

try {
  const result = await paymentService.process();
} catch (error) {
  logger.error(error);
  return fallbackResponse();
}

Reliable systems anticipate failure and handle it properly.

7. Logging and Observability

Observability is essential for production systems. AI-generated code rarely includes production-level logging.

Before deployment, ensure that the system has proper visibility.

Important components:

Structured logging
Request tracing
Error monitoring
Alerts for system failures

Popular tools include:

Winston
Pino
Prometheus
Grafana
Datadog

Good observability allows teams to detect and resolve issues quickly.

Final Production Checklist

Before deploying AI-generated code to production, confirm the following:

Dependencies are validated
Vulnerability scans are completed
Code passes static analysis
Performance issues are addressed
Scalability considerations are reviewed
Reliability and error handling are implemented
Logging and monitoring are enabled

Conclusion

AI has dramatically accelerated the speed of software development.

However, faster code generation also increases the risk of shipping insecure or unstable systems. Generating code is only the first step. The real responsibility lies in validating that code before it reaches production.

AI can write code. Engineers must ensure that code is secure, reliable, and production-ready.

The Next Leap in RAG Isn’t a Better Model - It’s Better Retrieval

Gaurav Talesara — Sun, 01 Mar 2026 14:09:56 +0000

For the last two years, most Retrieval-Augmented Generation (RAG) systems have followed the same architecture:

Chunk → Embed → Store in Vector DB → Similarity Search → Inject into LLM

This pipeline works.

But it also has a fundamental limitation:

Similarity does not always equal relevance.

And that’s where the next evolution of RAG begins.

The Core Problem with Vector-Based RAG

Traditional RAG relies on embeddings and vector similarity. The assumption is simple:

If two pieces of text are semantically similar in vector space, they are relevant.

In real-world production systems, this breaks down.

1. Arbitrary Chunking Breaks Context

Documents are split into fixed-size chunks.
Cross-references get separated.
Tables and structured sections lose meaning.

2. Similarity Is Not Logical Relevance

A chunk might be semantically close but logically unrelated to the question.

This becomes especially problematic in:

Financial reports
Legal documents
Research papers
Large enterprise PDFs

3. Retrieval Is Passive

Vector search retrieves the “closest” chunks.
It does not reason about where it should look.

Enter Vector-Less Page Indexing

A new approach is emerging: vector-less indexing, also described as reasoning-based retrieval.

One open-source implementation gaining attention is PageIndex:

https://github.com/VectifyAI/PageIndex

Instead of embedding everything into vector space, this method:

Builds a structured index similar to a smart table of contents
Organizes documents hierarchically using a tree structure
Uses LLM reasoning to navigate the structure
Follows cross-references across sections

The retrieval flow becomes:

Query → Reason → Navigate → Select → Answer

Instead of:

Query → Embed → Match → Return

This is a significant architectural shift.

Why This Improves Accuracy

In structured documents, relevance is often positional and logical, not just semantic.

For example:

“See Appendix G for revenue breakdown”
“Refer to Section 4.2 for risk disclosure”
“As discussed in the previous quarter”

Vector similarity alone struggles with these patterns.

A structured tree index allows the system to:

Understand document hierarchy
Traverse sections intelligently
Maintain context across related nodes
Treat retrieval as a planning problem

Retrieval becomes active navigation rather than passive matching.

Does This Replace Vector Search?

Not entirely.

Vector search remains powerful for:

Unstructured knowledge bases
FAQs
Customer support bots
General semantic retrieval

For highly structured documents, reasoning-based indexing may outperform traditional embedding-based RAG.

In practice, hybrid systems combining structured indexing and vector search may become the dominant approach.

Final Thoughts

The future of RAG will not be defined by larger models or faster embeddings.

It will be defined by how intelligently we retrieve context.

As systems move toward production-grade reliability, indexing strategy may matter more than embedding choice.

If you are building serious RAG systems, it may be time to rethink:

Your chunking strategy
Your indexing layer
Your retrieval architecture

Retrieval is evolving from vector similarity to intelligent navigation.

Before You Build Anything, Make Your Idea Visible

Gaurav Talesara — Mon, 23 Feb 2026 18:50:48 +0000

Most early-stage products don’t fail because of bad engineering.
They fail because the idea was never clarified before development started.

One thing I’ve learned working with startups is this:

Before you build anything, you need to make your idea visible.

It sounds simple, but this step is often skipped - and skipping it creates confusion, wasted effort, and expensive rework later.

The Common Pattern I See

Many founders and early teams do one of two things:

Keep the idea in their head
Jump straight into development

In both cases, clarity is missing.

Developers start building.
Features get added.
Scope expands.
Assumptions go untested.

And then a few weeks later, everyone realizes:

“This isn’t what we meant.”
“This isn’t scalable.”
“This isn’t what users actually need.”

The issue usually isn’t execution.

It’s that the idea was never made visible.

I’ve seen this pattern in both early MVPs and scaling products — and it’s surprisingly consistent.`

What Does “Make It Visible” Actually Mean?

It doesn’t mean creating perfect architecture diagrams.
It doesn’t mean over-engineering.
It doesn’t mean spending weeks planning.

It means answering a few critical questions visually:

How does a user enter the system?
What actions can they take?
What data moves where?
What absolutely needs to exist in version one?
What can wait?

This can be as simple as:

A rough user flow
A basic system sketch
A simple data movement diagram
A lightweight interactive prototype

The goal is not perfection.

The goal is clarity.

Why This Step Changes Everything

When you can see the product, several things happen:

1. Assumptions Become Visible

Hidden assumptions surface quickly when you map flows.

2. Scope Becomes Controlled

You start identifying what’s essential and what’s noise.

3. Technical Decisions Improve

Architecture becomes intentional instead of reactive.

4. Validation Gets Easier

It’s much easier to show something tangible and ask:

“Does this solve your problem?”

5. You Avoid Building the Wrong Thing

And that’s where most time is wasted.

I’ve seen teams save weeks - sometimes months - just by doing this step properly.

You Don’t Need Heavy Tools

Today, there are simple ways to do this:

Structured brainstorming
Basic flow mapping
Simple system views
AI-assisted breakdown of ideas
Lightweight visual prototypes

The important part isn’t the tool.

It’s the thinking.

**Clarity before code.

**

A Simple Starting Framework

When I approach a new idea, I usually think in this order:

User Flow – What does the user actually experience?
System Flow – What needs to happen behind the scenes?
Version One Filter – What is absolutely required for the first usable version?
Constraint Check – What can break? What will scale? What can wait?

This doesn’t take weeks.

Sometimes it takes a few focused hours.

But it completely changes the quality of execution.

Final Thought

Most ideas don’t fail because of bad development.

They fail because they were never clarified before development started.

Before you hire.
Before you code.
Before you build.

Make the idea visible.

Curious -
Do you usually visualize your ideas before building, or jump straight into execution?

If you’d like, I can write a follow-up post on:

The exact step-by-step process I use to break ideas into flows
Or the lightweight tools I use to turn raw ideas into something interactive

Let me know 👇

NVIDIA’s Open-Source Voice AI Is Quietly Changing Customer Support

Gaurav Talesara — Mon, 26 Jan 2026 11:47:17 +0000

For years, AI voice systems promised to transform customer support.

In reality, most businesses ran into the same issues:

Robotic conversations
High latency
Expensive, closed platforms
Little to no control over customization

That’s starting to change.

With NVIDIA’s PersonaPlex 7B, open-source voice AI has crossed an important threshold — real-time, natural conversations are finally practical for real businesses.

And this shift isn’t just technical.
It’s operational.

What Is PersonaPlex 7B (in simple terms)

PersonaPlex 7B is an open-source, speech-to-speech AI model.

Unlike traditional voice bots that rely on multiple steps
(speech → text → LLM → text → speech), PersonaPlex operates using a single, unified pipeline.

What this enables:

The AI can listen and respond at the same time
Conversations feel more natural and human
Latency is low enough for real customer interactions
Voice and persona can be customized without heavy fine-tuning

In short:
It behaves less like a bot and more like a real agent.

Why This Matters for Businesses (Not Just Engineers)

This isn’t about replacing support teams.

It’s about giving businesses a new first layer of interaction.

With modern AI voice agents, startups and companies can:

Offer 24×7 customer support
Instantly handle repetitive and common questions
Reduce response time without increasing headcount
Support customers across time zones
Experiment without locking into expensive SaaS platforms

This is especially impactful for:

SaaS companies
Marketplaces
E-commerce brands
Fintech and logistics businesses
Internal IT or HR helpdesks

Where AI Voice Agents Actually Work Today

AI voice agents are most effective when used intentionally.

Some practical, real-world use cases include:

Customer support triage (FAQs, order status, basic troubleshooting)
Inbound sales inquiries
Appointment scheduling
Onboarding and walkthroughs
Internal employee support
After-hours support coverage

In these scenarios, AI doesn’t replace humans —
it removes friction before humans need to step in.

The Real Challenge Isn’t the Model

The model being open source is the easy part.

The real work — and real value — comes from:

Training the agent on business-specific knowledge
Designing the right voice personality and tone
Ensuring low-latency, real-time performance
Integrating with CRMs, ticketing systems, and workflows
Handling edge cases and smooth handoffs to humans

This is where most businesses struggle — and where thoughtful implementation matters.

Open Source Changes the Game

Because PersonaPlex is open source:

Businesses keep control of their data
There’s no vendor lock-in
Customization is possible
Infrastructure decisions stay flexible

For startups, this means:

Faster experimentation
Lower long-term costs
More control over the customer experience

We’re moving from “AI voice demos” to production-ready systems.

What This Means Going Forward

AI voice agents are no longer a future concept.

They’re becoming a practical business tool — especially for teams that want to scale support without scaling complexity.

Companies that explore this early won’t just save costs.
They’ll design better customer experiences.

As with every platform shift:

Early understanding matters more than hype
Implementation matters more than tools

Final Thoughts

Voice AI is quietly entering a new phase.

Not flashy.
Not perfect.
But finally usable.

If you’re building or operating a business that handles customer conversations, this is a space worth understanding deeply — sooner rather than later.

Let’s Connect

I’ve been working hands-on with open-source AI voice agents and real-world integrations.

If you’re evaluating this for your product or business:

LinkedIn: https://www.linkedin.com/in/gaurav-talesara-8099ba147
Email: gaurav@ciphernutz.com

Happy to exchange notes or walk through real use cases.

PostgreSQL Didn’t Fail at Scale -My Architecture Assumptions Did

Gaurav Talesara — Fri, 23 Jan 2026 19:36:11 +0000

When I read “Scaling PostgreSQL to power 800 million ChatGPT users”, I didn’t read it as a Postgres success story.

I read it as a reality check.

Because like many developers building SaaS products, I’ve caught myself thinking:

“This will work for now… but later we’ll need something more scalable.”

Later usually means:

sharding
multiple databases
complex infra
future-me’s problem

Turns out, future-me might be overthinking it.

Building SaaS Makes You Fear Scale Too Early

While working on SaaS-style platforms (hiring tools, dashboards, internal systems), PostgreSQL is often the first thing people want to replace.

Not because it’s failing.
But because we assume it will fail.

The OpenAI post forced me to pause and ask:

If Postgres can survive ChatGPT traffic, what exactly am I afraid of?

The Database Wasn’t the Hero — Discipline Was

What impressed me wasn’t the scale.
It was the restraint.

One primary database
Reads pushed aggressively to replicas
Bad queries treated like production bugs
Write-heavy or non-core data moved out

Postgres wasn’t used as a junk drawer.
It was used as a core system with clear boundaries.

That’s something I don’t always do in my own projects.

Reads Are the Silent Cost Killers

Most SaaS apps are read-heavy:

dashboards
candidate profiles
activity timelines
analytics views

Yet we design everything as if writes are the main concern.

This story reminded me:

Scaling isn’t about handling more writes — it’s about protecting the primary from reads.

Once that clicks, architecture decisions become simpler.

Simplicity Is Not Laziness

I used to think:

“A simple architecture means it won’t scale.”

Now I’m starting to believe the opposite.

Simple systems:

are easier to debug
fail more gracefully
survive longer than clever ones

OpenAI didn’t avoid complexity forever.
They just earned the right to add it later.

What I’m Taking Back to My Own SaaS Work

After reading this, my mindset changed:

I trust PostgreSQL more
I fear premature sharding less
I care more about query quality than new tech
I think harder before adding “just in case” infrastructure

Not everything needs to be distributed.
Not everything needs to be clever.
Most things need to be boring and reliable.

Final Thought

PostgreSQL didn’t scale because it’s magical.

It scaled because engineers respected its limits
and designed around them instead of fighting them.

That’s probably the real lesson for anyone building SaaS today.