You read between the lines. An agent reads the lines.
In the first post I argued that building an agent is rarely the hard part, the hard part is choosing where to point it. This one sits a layer below that - once you have chosen the node, the question is whether the data underneath it is in any shape for an agent to read.
For a long time enterprise data was built for a human eye. We built dashboards, we laid out reports, and we left the hard-won context in the heads of the analysts who knew which column was the real one and which join never to trust, and for a human consumer that worked well enough. An agent is a different kind of reader. It cannot squint at a chart, it cannot ask the analyst what "rev_final_v2" was meant to mean, and it will take your schema at its literal word and then guess, with total confidence, at everything the schema left unsaid. So the data that served the dashboard era is surprisingly often the wrong starting point for the agentic one.
The shift I find useful to hold in mind is the difference between a shelf of brochures and a catalogue you can compute from. A person can flip through the brochures. An agent needs the catalogue. In this post I try to lay out how you might build that catalogue, which data is worth building it from first, and a few of the places people tend to go wrong, including the one word in this whole conversation that I think is most often misunderstood - ontology.
That agentic AI is going to reshape how enterprises build and buy software has become a fairly popular claim, repeated by most of the people who sell software and a good number of the people who buy it. The more useful question, and the one almost nobody seems to start with, sits underneath it - now that you can put an agent almost anywhere, how do you decide where it actually belongs?
What is wrong with how most companies do this today?
Walk into most companies that have started doing something with AI and you will find a scatter of agents, copilots, summarisers and chatbots, every one of them attached to whatever happened to be convenient at the time, and almost none of them attached to anything that anybody measured first. A pile of technology, sitting on top of no particular thesis. This is perfectly fine when you are early, because what you are really buying in that phase is literacy - you are learning what these systems can and cannot do. The trouble shows up later, once the pile has grown and you sit down to ask yourself what all of it was worth, because by then "we built it because we could" might have quietly turned into a time/cost sink.
So the question for any company past that first phase changes shape. It is no longer whether AI can be made to work somewhere, because it almost always can. It is whether the thing you have pointed it at is worth the money, the maintenance, and the attention it will go on consuming for years. That needs a roadmap, and a roadmap needs some discipline sitting behind it.
What framework should replace it?
I find it useful to go through five lenses, and to go through them strictly in that order, because the order turns out to be most of the discipline. You begin with the stakeholders the company exists to serve. You work out the job each of them hired the company to do. You trace the value streams that deliver those jobs, you put a number against each value stream and rank them, and you narrow down to the two or three that genuinely matter. Everything else you leave alone, for now.
UI first to AI first software application development
That business/SaaS applications are going to be impacted by Agentic AI, has been a popular idea put forth by many industry leaders. In this note, I try to map out this potential future reality and pay specific attention to what this would mean from an architectural perspective, when entering an Agent first interface and away from a human-user centred interface. A shift that will imply moving away from interfaces designed primarily around human interaction patterns towards dynamic, agent-managed workflows that anticipate user needs, autonomously perform tasks, and continuously adapt through real-time feedback.
Note - This assumes the reader has an architectural bent of mind and is curious about the agentic application landscape and how it may evolve.
What does this future look like?
In the current “UI-first” paradigm, SaaS applications deliver value through structured interfaces, performing predefined logic that enables workflows and stores and retrieves interstitial and final datasets. However, they do not provide any significant decision-making capabilities.
In this emerging “AI-first” paradigm, agents become the primary interface to capture intent and provide the desired results. Everything else is behind the screen—no more forms, screens, or tabs. They will reason, orchestrate tasks, make judgments, access datasets, and even dynamically interact with other applications or APIs.
Users will transition from manual navigation across multiple software tools to engaging with intelligent agents that anticipate needs, autonomously execute workflows, and refine their actions through real-time feedback. This shift promises greater dynamism, enhanced efficiency, and significantly more autonomous enterprise applications. It is imperative that while we design in the new paradigm, we are not limited by rules of the UI first world!
The key architectural dimensions that will undergo a paradigm shift to enable this transition are:
The User Facing Agent
Agent Orchestration
Agent Identity
Observability and Guardrails
Data models and governance for Agents
What will change and how?
The User facing agent
Consider a simple case of a customer service/ticketing application. A customer is interacting with an AI support agent to fix an issue with an order placed by the user. The user-facing agent understands basis the interaction that it needs to
Authenticate the user (User_Auth agent)
Possible resolutions are to either offer a full/partial refund and the modality (credits vs cashback)
Eligibility verification for the return (Return_verfication agent)
If eligible, Initiate return process (Return_processing agent)
Inform the user of what to expect in terms of the resolution and seek acknowledgment
Finally, compile the multi-agent responses into a coherent, human friendly response.
Segregating agents in a purpose oriented manner helps keep the prompts tight - This will be important not only for better accuracy, but also key to managing policies around context, tools/API access, traceability and observability.
I am working with a healthcare BPM firm on building an agent-first application for one of their process lines that is related to healthcare insurance claim processing. They generate a third of their revenue from this process with 20 large customers accounting for 80%. The process is run by 1000 human agents with a medical/pharmaceutical education that log into an UI first application on a daily basis to process the payment workflows. Early results indicate that we need about 5 AI agents per sub-process per customer (there are 8 sub-processes) for best outcomes. This translates to 5*20*8=800 AI agents for one process. The need for a powerful orchestration layer quickly becomes apparent.
Agent Orchestration
One of the biggest paradigm shifts is in this new middle-ware layer. When dealing with swarms of agents this layer will help both manage execution and with resource optimisation. Once the tasks are broken down and assigned to agents (using open protocols like MCP or A2A), dependencies are understood and enforced (validating interim outputs, parallel vs serial execution, error handling etc…) and the final API response is sent to the user facing agent - in the happy path.
Real-world systems rarely follow the happy path. APIs go down, agents hallucinate, configurations expire etc…! Orchestration will need to be composable and adaptable - log, queue up for reattempts, route to a human, if possible, and if not, preserve state to be picked up by a UI first application!
Most agentic systems will be multi-model to achieve the right balance between cost and quality and this too will need to be orchestrated. In addition to static routing rules based on context of the use case, companies might need to implement dynamic routing to balance loads or cap inference costs.
This dynamic new middle-ware is the natural evolution in the agent-first era. Integration management is no longer a hard coded sequence of API calls that are ultimately linked to action buttons and forms. It is a beautiful symphony that intelligently handles a swarm of industrious agents.
Agent Identity
With AI agents entering the scene, Identity and Access Management (IAM) faces a twin challenge: managing the credentials and permissions of autonomous non-human actors that perform tasks, and defending against malicious AI agents or misuse . In the near future, it’s easy to imagine an “army” of bots operating within and across companies – some authorized by your business, others possibly deployed by attackers. The scale and speed of these agents demands a rethinking of security controls.
Securing AI-first applications is about to get far tricker. The challenge stems from the ability of agents to behave intelligently and dynamically and thus in unpredictable ways, by design. IAM in this new world will be built on at least 3 legs - Agent identity and authorisation, access controls and observability.
Companies are already building AI agents by enabling OAuth flows and token-based “service accounts” for authenticating API calls by agents and fully by-passing the traditional password based authentication. Open protocols like MCP and A2A are emerging standards that provide a secure and authorised interface for external tools and data.
The dynamic appeal of an AI-first application necessitates that it is provided with access to a variety of data sources - both structured and unstructured, with richer permissions - read, write and modify, access to APIs - internal or external that can GET, POST, PUT or more!
Fine-grained, context aware access controls (not very dis-similar to zero trust models) will become increasingly important to managing this beautiful chaos. Emerging models like attribute or policy based access controls (ABAC/PBAC) already provide a mechanism to marry context along with identity. An agent may be provided with access to payroll data of an entire department only when the ultimate user is an HR manager and otherwise restrict it to only to the specific employee it represents. For most simple cases, just implementing stricter controls may suffice. An agent that needs access to your email data can only be given read access. Other hybrid models might be required for sensitive data/actions that involve time-limited, human authentication as an added layer of security. An agent that is empowered to send emails on your behalf can still draft it, but will need a human authentication before the email is sent.
Finally, observability provides defensive capabilities. Every action an agent takes should be logged and made auditable. If an AI tries to access a forbidden resource, it should be flagged and blocked in real-time, similar to how security systems detect anomalous user behavior.
Observability and Guardrails
But it goes beyond just the security aspect of AI-first applications. When autonomous AI agents take over tasks behind the scenes, there is no longer any visibility. In traditional systems, a process is visible because a human user performs steps, enters data, and can report issues. With AI-driven workflows, work becomes opaque unless intentionally instrumented - what happens, when and why? This loss of transparency can erode trust – if something goes wrong, how do we even know, let alone debug it?
In addition to detailed logging of factual raw data is important, intelligent summarising and processing of outputs will act as guardrails. These could be heuristics based - A refund
processing agent’s final refund recommendation is cross checked against at SOPs or Agent based evals. Yes, a specifically created class of agents that monitor responses, grade, classify and even take action. Block when abusive or unrelated information is about to be shown to the user or merely log the tone - 5% of the responses were confusing.
If thought through well, AI-first applications can transform into powerful self-healing machines. Agents monitoring logs, failures, inputs that led to marked variances in output quality can reflect on what caused it? Playing the role of a tutor they can build out prompt libraries that can prevent or reduce sub-optimal output.
In most UI-first applications real-time observability or guardrails was not practical. Software application testing was mostly test-and-forget before production deployment. In the AI-first era, they will be inevitable and the scope of traditional software testing, manual or automated will significantly diminished.
Data Models and Governance
Data governance in an agent-driven era means understanding and enforcing what data the agent is trained on, what data it can access at runtime, and how it uses and outputs that data. This will be key to provide both high quality results as well as prevent security lapses. Agents unleash their true potential by possessing the capability to reason, access and create multiple data types - structured, unstructured and modalities - image, text and video. They will do this both with internal systems and with third-party systems.
Creating RAG or Knowledge graph based context data stores will almost need a white-listing based approach. Prompt libraries will help with maintaining, debugging and for self-healing of the agent swarm along with tool libraries to manage fine-grained capabilities.
Data sets that will be read or written by agents might need to be labeled and categorised with rich metadata including security/sensitivity levels. In our earlier customer service example - Order information may be general access while payment/credit card information may be labeled confidential access. ABAC/PBAC models can use such metadata to control access.
During onboarding, an audit agent could inspect all the data that it can get access to, to provide a summary - like a pre-check. A throwback to the days of installing an application in your windows desktop that would both ask for the location and caution you if you do not have enough storage for installing the application.
With recent innovations like memory management for agents, AI-first applications could provide personalised experiences across sessions. Creating and storing state will also need to be governed.
So, what?
I interact with and advise management leaders, board members and customers of our portfolio companies, specifically - IT services, software product companies and software infrastructure companies. This change will mean:
IT services businesses providing application engineering, development and testing services are re-thinking their approach. Everything from how and what they sell (more AI-first), how they deliver software (GenAI driven SDLC) to how they adopt this internally to boost their productivity.
Software application companies have an opportunity to leverage this shift. UI-first and AI-first capabilities will co-exist during the transition. Most companies are augmenting AI interfaces, albeit as an overlay with limited heft. This is a layover and not the destination. Their distribution and access to customer data is a moat that will serve them well against most AI upstarts.
Infrastructure software companies that provide API gateways, iPaas, IAM and data platforms are gearing up to host AI-first applications and will provide solutions to help manage the dimensions -- from Orchestration to Data governance. Make it easy for software builders to embrace this change faster - through their platforms!
However while each one will move their pieces on the board differently, one thing will be common to all. Building powerful and dynamic agents will require a sophisticated appreciation of the domain and the business context. This was not really true when we were creating forms, designing workflows or building databases.
Aah and yes, we are going to be writing a lot more software to bring about this change. More by software agents than human engineers. But, that’s a whole different topic on GenAI driven SDLC.
The pace of change is real. I am writing this in June 2025 and 2 months before ChatGPT could not access google drive directly. Today it can access my entire Google drive and surprisingly, I feel like I have had this forever. Token limits have grown 10X in 3 months, while their pricing has dropped by 10X in 6 months.
In the first part of this blog we discussed one of the strategies that I have found helpful in optimizing call center operations. In this concluding part, let’s take a look at why and when this strategy might not work or be as effective.
Adding another 50 seats comes with its own costs. It’s a fixed vs variable cost issue. If your fixed costs are going to increase because you may need to rent out a whole new space or because you are going to have to on-board new vendors for sourcing and training or because you have to add a new server or a PRI line then this may not work.
High lead cost is an important reason for this strategy to work. If your business is that of selling low cost items that have a low lead cost (assumption for running a viable call center in the first place) this may not work for you. Also, while I am not a big fan, cold calling models too tend to have low lead costs and subsequently low conversion rates. You are better off throwing the leads in to the hopper and have it shoot out automatically to your agents.
Experienced call center managers know that it is no picnic to increase conversion rates, even by 10%. Some things to keep in mind while doing this is to ensure co-ordinate changes with the rest of the operations. Having higher quality conversions may require agents with better communication skills and this may require a new hiring strategy. With the extra time that the agents are expected to spend per lead, their scripts, approach and training needs to be revisited. More focus should be given to need identification and to explain product differentiation.
Another intended consequence that agents need to be trained for is that they are going to have to generate more follow ups. If they are not already being organized about it, they should now start. There are tools available to track and execute follow ups better. Follow ups need to become part of the team lead’s dashboards and definitely warrants a discussion in the daily morning huddle. Closure tactics like a free trial or a discount may help push the conversion rates better.
While I have assumed that this may not be the case, poorly run call centers should first fine-tune their operations before going down this path. Industry best outbound call centers typically have a productive talk time per day of 4.5-5 hours. If your team is clocking significantly lower than this then lowering the leads per agent may actually back-fire. That is because they are not spending time that they actually do have to meaningfully engage with potential customers.
On the other hand, if you are already doing a fabulous job and are near theoretically maximum conversion rates, then too this will not work. But hey, if that’s the case stop reading this and go ask for a raise ;).
Inbound operations might not fit this model too well. I have used this approach successfully twice in my career so far, both have been for outbound operations. Maybe its because I am uncomfortable with the high variance in lead flow for inbound operations!
Call centers are a big part of doing business in India. While traditionally these have been used to provide quality support at a relatively lower cost, in some industries these are a key component to boost sales - Telecom, Real estate, Financial services and even for disruptive internet companies.
Not having risen through the ranks of a call centre, I have huge respect for someone who has. Arguably, in all of my businesses, the job of the call centre executive is the toughest. Having to converse in an impersonal medium, with complete strangers, usually from diverse backgrounds, when they are not expecting to talk to you, does not come naturally even to the most extroverted amongst us! In lead driven sales processes, the average executive would manage to close between 0.5-2 sales a day after talking to 30-150 prospective customers who are interested in your product/service. At best that is a 93% rejection rate that she faces, on a daily basis!
There are two dimensions critical to run an effective call center ops - first principles based processes and quantitative methods based administration.
Call center leaders who rise through the ranks are best suited to design the first principles based processes. Hiring - “What attributes should we look for while hiring?”; Training - “How should my executives talk to prospective customers?”; Quality control- “What are clear Do’s and Don’ts that I should watch out for to ensure my customers have nothing but the best experience?”
Given the mass scale of their teams they also tend do a good job with quant based ops administration. Akin to running a tight assembly line, they fine tune their dialer pacing ratios, adjust training batch sizes, monitor talk times, avail rates and conversion rates through numerous reports and dashboards that give a pulse of the operations. But, a great leader would go beyond just their function to understand how their team can maximize its value to the organization.
The following is an illustration of how I have found most leaders optimize their outbound operations [File hosted on Google drive].
“Every seat is profitable. Marketing, I need more leads. Let’s get more revenue!”
The real story of course, lies in the cost of leads.
A whopping 90% profit margin has turned into a loss making operation!
“Hey, that’s marketing’s problem!” Really. No leads, no revenue for the call center team.
Now, let’s take this further. Which team is better?
Team 1: No. of agents - 100 Revenue per agent - 99,000
Team 2: No. of agents - 150 Revenue per agent - 72,600
Oh and of course they have the same marketing budget and generate the exact same quality and quantity of leads.
9 out of 10 times call center leaders and even business heads choose Team 1. I choose Team 2.
Let’s dive into the above executive summary dashboard. For the math to add up, the numbers should roughly fall like so:
The reason I can justify a 50% larger team with just a 10% higher conversion rate is the relatively high cost of marketing. All the while with higher overall revenue and profitability.
This makes sense intuitively too. A sales agent can spend more quality time with 50 customers - understanding their needs, explaining the product better and maximizing the probability of the sale. Throwing more leads to an agent discourages him from doing this and he starts hunting for easy kills.
Is this always the right strategy? No.
Part 2 of this entry will talk about when this approach fails. Coming soon...
As companies evolve along the technology dimension, they inevitably need to move into matrix reporting structures. The primary advantage of this structure is efficient flow of information and the enablement of decision making by people who are closer to the customers (and typically further lower in the organisational hierarchy). The challenge in this approach is the confusion about the pecking order between functions, especially during conflicts. Who takes the call?
I have been asked this question numerous times over the years. And when asked, I tell them my Macroeconomics story.
Ferraris and Bananas
There is a mythical planet with two countries- Bananaland and Ferrariland.
Bananians are hard working geniuses when it comes to farming and naturally get bananas.
Ferrarismos, quite understandably adore their Ferraris. They are experts in highly technical fields - Engine design, fluid dynamics and aesthetic design.
All people in this world need only 2 things to survive. Super fast cars and bananas.
Both the countries had been trying to make both products, until they met with each other and realised- Hey, we can trade! There was nobody better than the bananians who could make the most and best bananas and the story was similar across the pond.
When they started trading the following happened,
People in both places enjoyed their work. No one felt they were doing boring work or unsure of how to do their work.
The quality of bananas and Ferraris in the world was amazing.
The overall number of bananas and Ferraris were higher than ever.
Things were great till one day there was a fight in a local bar between a local Ferrarismo and a visiting bananian.
Hurtful things were said. Sides were taken. And soon, trading stopped.
The Ferrarismos obviously believed they were superior. After all making super fast cars was not easy and was definitely something that the guys from the other country could even understand! On the other hand, Bananians knew that if not their food, the Ferrarismos would starve to death.
Bananians hated Ferrarismos for being smug and Ferrarismos hated Bananians for not being in the same league as theirs.
Things were back to how they were before trading began. No opportunity was missed to make the other country feel that they were not doing a good job in what they were “supposed” to be good at.
Lot of money was spent in showcasing how each country knew more about the other’s expertise. Occasionally when either needed help, they would reach out to each other. More often that not, war would break out.
Finally, God intervenes and calls for a joint meeting with the two kings and issues his 3 commandments.
Respect your need. You both need a Ferrari and a healthy supply of Bananas
Respect each other. Nobody can make a better tasting Banana than Bananians and vice versa
Don’t compare Ferraris and Bananas. You are both skilled in very different areas. If you feel compelled to compare, find Ferraris from other planets to compare.
And as a final piece of advice asked both the kings to ensure both the countries conduct periodic inter-country fairs for people to showcase their technical competence. New learnings, new experiments, failed attempts in bananaland and Ferrariland etc..
As long as they stuck to the above, there will be no war!
Oh and who takes the call? Of course, it is the person with the most relevant functional expertise to the problem.
There is an old story of a person arriving at the pearly gates of Heaven and asking St. Peter for an introduction to the greatest general who ever lived. St. Peter points someone out and says, “There he is, the greatest general in the world.” The new arrival is shocked. “No way!” he exclaims, “That’s not the greatest general … that guy isn’t even a general. I knew him on earth and he was just a cobbler!” St. Peter responds: “I know. But if he had been a general, he would have been the greatest of them all.”
The above excerpt is from “99% invisible”, Episode #220 - Dec 07, 2016
Professionally, many of us are trying to figure out if we are cobblers or generals, or a crazed mutant that is half-general and half-cobbler!
As we evolve as a society, the need for people with multi-dimensional skill sets has increased greatly.
Today, a graduate student in an “Artificial Intelligence” class will not uncommonly find his classmates from a Biology, Psychology, Linguistics, Mathematics, Signal Processing and Computer Science background!
My own journey to become a Product Manager arose from my interests in software application design, program management, user behaviour, statistics and design. Fields that require one to simultaneously have a strong inclination towards logic and creativity.
Is there a parallel profession to product management? If this is something you think about then the creative architect is a good listen.
As a bonus, you might even discover your favourite interview question for Product Managers.
Mine is, “If human beings are to grow a third limb, where would you put it and why?”
The Kung-fu panda movies, apart from being really cute and awesome, carry oodles of management wisdom. The recently released Kung-fu panda 3 does not disappoint in both these areas. It is a job well done.
Here is my favourite series of dialogues from the latest one:
Po: [Shifu has made a flower bloom with the power of chi] Woah! What was that?
Shifu: That was chi.
Po: Wow! What's chi?
Shifu: The energy that flows through *all* living things.
Po: So you're saying if I-so you're saying if I teach, I'll be able to do cool stuff like that?
Shifu: No, I'm saying if you teach, *I'll* be able to do cool stuff like that.
Po: Oh.
Shifu: Mastering chi requires mastery of self. Oogway sat alone in a cave for *thirty* years, asking one question: who am I? Who am I? I'm lucky if I get five minutes before you interrupt...
Po: Aw, so now I have to sit alone in a cave for thirty years?
Shifu: Eventually. After you master teaching.
Po: Teaching? There's no way I'm ever gonna be like you!
Shifu: I'm not trying to turn you into me; I'm trying to turn you into you.
[courtesy: IMDB]
On the ‘style of coaching’ dimension, leadership consists of two approaches. One, that focusses on the team members’ weaknesses and takes steps to improve upon them.
“You are only as strong as your weakest link”
Keep making your team members stronger, then you would have raised the bar of your team, over time.
The other one that focusses on a team’s strengths.
I strongly endorse the “strengths based approach”
It is very hard and expensive (time, effort and sometimes real money) to change people fundamentally. The weakness based approach runs the risk of negativity and frustration seeping through while trying to improve team members. Especially in highly competitive teams like those that tend to be part of startups.
For this to work, the composition of your team needs to be carefully done; Build teams with strong complementary skill sets.
If done well, the team starts to build on its collective success, starts to believe in its capability and really starts pushing the envelope.
The leader can then focus on cheer leading, guiding and succeeding.
Is there a correct approach? No.
The strengths based approach is very similar to the theory of comparative advantage. And, like with macroeconomic theories, there is no correct answer.
If anything, in the long run the consistent one wins.
Have you ever walked into a house and had an indescribable feeling that it just feels cheap? A professional builder would walk in and give you a laundry list of shortcomings: uneven drywall, gappy hardwood floors, hollow-core doors, and cheap hardware. But most people just have a gut reaction. Like a well-built home, great software focuses on giving its users hundreds of small, satisfying interactions. A great transition in a mobile app gives us the same feeling we get from using a well-made door handle on a solid oak door? you may not be able to put your finger on it, but man, does the house ever feel well built. Slack is really fun to use. It feels like a well-built house.
A quick look into some of the considerations of building a great product around content. A large part of this deck focusses on building #edtech products.
This is the slide deck that I used for a short talk that I was part of in early January. I have been meaning to post them for a while now and have finally gotten around to doing it. My todo app seems to be really helping, and it feels great to strike/swipe things off. This is my 8th task for the day and the app has me hooked (at least over the last 2 weeks).
The talk expounds on my observations on what makes for a good product in the edtech space. I outline a 5 step framework that would help one go about when building any edtech product. It was a short, informally styled chat and I thoroughly enjoyed the event. Both the process of forcing myself to cobble together my thoughts on the topic and actually interacting with the folks in the audience. It should be a fairly fun read with lots of examples and visuals to outline the main points.
I have written earlier about how humanity is headed for greater days because of people's ability to build upon each other's ideas. The WWW has accelerated our capability best ourselves at a phenomenal rate which was unthinkable in the pre-80's!
Case in point: This is Jakob Nielsen's article titled "In the Future, We'll All Be Harry Potter".
Mirrors comment on the reflectee's appearance. This will surely be a commercial product. In the far future, expert systems might issue the commentary, but in the interim it could be provided by networked fashion consultants: either cheap staff in low-salary countries or busybodies who will gladly appraise other people for free.
This is a blog entry I stumbled upon yesterday by @AmitKlein
At StartupGiraffe we’re really interested in the rise of smart devices. We wanted to dig deeper into building software for custom hardware by building a prototype. We went through a discovery/brainstorming process on what are all the objects in your house, and what could we make smarter with software (specifically embedded android). While we had a bunch of goodish ideas (a smart stove, chair, shoes), we ultimately settled on an Android Mirror.
I am positive there are a thousand more examples floating around us everyday. Nevertheless, it feels great when you take the time to acknowledge the 'serendipitiness' of all of this.
