Some songs begin softly and remain soft.

But Poove Ilaya Poove does something else.

It starts so gently, with Malaysia Vasudevan (MV) almost melting into the song. His voice does not enter with force. It just flows in.

For a few seconds, your heart settles down, thinking this is going to be a soft romantic song.

But Raaja and MV do not allow you to stay in that space.

Very early, the song takes an unexpected lift. It is almost as if Raaja is saying, “Don’t expect a standard romantic song. This will be romantic, yes, but also peppy, playful, and full of movement.”

And then slowly, Raaja starts increasing the tempo along with the music.

Within a minute, the song reaches a kind of small crescendo. When MV sings “Ennaku thaane,” something happens. The heart, which started slowly, suddenly starts racing.

And the way MV sings that line, it sounds so easy.

But try singing it from the start and reaching that lift properly. Only then you realise how difficult it is. I have tried it many times, and I still cannot get it right!

That is MV.

You almost want to run behind him and ask, “Boss, why are you running so fast?”

And he may simply say, “Raaja dhaan appadi paada solraaru!”

But what MV does after hitting that crescendo is even more beautiful.

He melts again.

And then, before we realise it, he starts climbing the hill once more.

That movement from melting to rising is so special. Only MV can sing like that. He does not just sing the tune. He bends with it, melts inside it, and then rises with it.

That is the joy of this song.

Then comes the first transition around 1:01.

The “la laa laa” portion begins with a typical ensemble. Nothing too fancy on the surface. But there is one small standout: that sweet santoor-like instrument appears for a short span. It comes and goes quickly, but it leaves a beautiful taste.

After that, the music moves into a familiar light music instrument cluster. The transition continues till around 1:38. Individually, the instruments may feel regular. But the way Raaja combines them makes the whole passage beautiful.

Then he comes back with “kuzhal valarndhu alaiyaanadhe,” and the song moves into a beautiful rhythm.

Only now we realise that the same santoor-like colour has returned. This time, it is not just a passing sparkle. It becomes the instrument that answers MV’s lines.

That is such a beautiful touch.

Raaja introduces that sound quietly in the transition, and then uses it to converse with MV’s voice.

Every line MV sings seems to get a reply from that instrument. I may not know whether it is actually santoor or something else, but the way it responds to his voice creates an indescribable feeling.

Then comes the second transition around 2:25.

This one is even more beautiful.

The flute begins, probably supported by bass violin, and then the violin cluster enters. It feels like the flute is asking questions and the violins are answering.

That interaction is so melodious.

It is not just an interlude. It feels like a conversation inside the song. The flute, the deeper strings, and the violin ensemble together create such a sweet flow that the heart does not know what to do.

Should it jump?
Should it run?
Should it slow down and enjoy?

Raaja happily confuses us.

In the final stretch also, MV melts again, and then comes that “Ennaku thaane” kind of lift. The same excitement returns.

This combination of Raaja and MV is very unique. Raaja gives the song these sudden emotional waves, and MV sings as if he knows exactly how to float, run, melt, and rise within them.

The magic starts in the heart and ends there. No use of brain here!

You feel Raaja’s music through the transitions, twists, interludes, and interactions, all inside one song.

Maybe that is why these songs stay with us for decades.

Kozhi Koovuthu came in the 1980s. We are in 2026, and we are still trying to understand what Raaja did inside this one song.

But that is the thing with Raaja.

He leaves us searching for an explanation.

Finally, his music cannot be fully explained.

It has to be felt.

By the time this song ends, we feel like we have just had a full feast, topped with a very nice ice cream and jalebi.

And we have been successfully served the magic!

Why a Goal Is Not Enough

One of the easiest ways to start using an AI agent is also one of the most dangerous.

We give it a goal.

“Investigate why this invoice has not been paid and resolve the issue.”

At first, this sounds reasonable. It has a business object. It has a problem. It gives the agent room to think. That is usually the promise of agentic AI: don’t prescribe every step, let the agent reason its way through the work.

But the moment we try to use this in an enterprise system, the instruction starts to look less clear.

What does “resolve” mean?

Does it mean identify the reason for the delay? Gather evidence? Contact the supplier? Update the invoice record? Recommend the next step? Decide the case can be closed? Approve payment?

A human may understand the boundary because they bring organizational context with them. They know their role, authority, escalation path, and the habits of the process. An agent does not inherit all of that automatically. It receives the goal, the context we provide, the tools it can access, and whatever boundaries the system has actually made explicit.

If those boundaries are not clear, the agent has to infer them while doing the work.

That is a problem.

We wanted the agent to use probabilistic reasoning to decide how to pursue a responsibility. We did not want the agent to decide what responsibility had been delegated in the first place.

The opposite mistake is also possible. We can remove ambiguity by scripting every step.

Retrieve the invoice. Compare it with the purchase order. Check receipt status. Inspect supplier correspondence. If the amount differs, ask for clarification. If receipt evidence is missing, route the case for review.

That may be a perfectly valid workflow. But then we should be honest about what we have built. We have automated a procedure. We have not really delegated agentic work.

The useful space sits between these two extremes.

An agent should not receive an arbitrary natural-language goal and decide for itself what work it owns. But the system should also not prescribe every internal step so tightly that the agent has no meaningful reasoning left to perform.

This is why agentic work needs a contract.

The First Boundary: What Work Can This Agent Accept?

The first part of that contract is the kind of responsibility the agent is designed to accept. I call this an Assignment Type.

An Assignment Type is an explicit, bounded operational responsibility that a particular agent has been designed to accept. It is narrower than an open-ended goal, broader than a workflow procedure, and stable enough for another system to invoke through a contract.

That “particular agent” part matters.

Almost all leading language models can talk across many enterprise domains in the same conversation. But an enterprise agent is not just a model answering questions. It is enterprise software acting in an enterprise context. If it reads enterprise data, changes enterprise records, communicates externally, consumes governed systems, or influences a business outcome, the enterprise remains responsible for what happened.

A finance investigation agent should not accept every finance-related request merely because the underlying model can discuss invoices, payments, suppliers, procurement, and accounting. The agent’s responsibility has to be narrower than the model’s language capability.

The model may have broad knowledge. The agent should have bounded responsibility.

This is why a generic `/execute` interface is so tempting and so dangerous. It treats the agent as if its responsibility can be discovered at runtime from whatever natural-language goal it receives. That may be fine for a personal assistant or exploratory tool. For enterprise work, it is not a valid enterprise contract.

For example, “resolve accounts payable issues” is too broad. It names an area where something may be wrong and asks the agent to work out what responsibility it is supposed to carry.

At the other extreme, “compare the invoice amount to the purchase-order amount” is too narrow. That may be a useful step, but it is not the full responsibility.

A useful Assignment Type has to sit between those two extremes. It should name a bounded responsibility the agent can accept, without reducing that responsibility to a single procedural step.

The Assignment Type answers only the first question:

What kind of work may this agent accept?

It does not yet describe the particular work in front of us.

Turning Responsibility Into a Specific Assignment

That is where the Work Assignment comes in.

A Work Assignment is a contextualized instance of an Assignment Type. It binds the agent’s responsibility to a specific enterprise situation.

In the invoice case, this is where the abstract responsibility becomes a particular invoice, a particular purchase order, a particular supplier, and a defined set of relevant records. The agent now has a real piece of work. But the system has still not told the agent exactly how to reason. The path remains open inside a bounded assignment.

Even that is not enough.

The caller also needs to know what result should come back.

The Result Must Be More Than a Paragraph

This is the expected outcome.

For predictable autonomy, the expected outcome should define a structured result the delegated responsibility must return so the invoking process can decide what happens next, without giving that next decision to the agent.

In the invoice case, the agent should not simply return a paragraph saying, “The discrepancy has been resolved.” That tells the surrounding workflow too little. It should return an investigation disposition: what discrepancy was found, what explanation is supported, what evidence was reviewed, what remains unresolved, and how much confidence or uncertainty attaches to the finding.

For example, the result category might be:

• discrepancy explained by supported evidence;

• discrepancy explained but evidence incomplete;

• conflicting records found;

• supplier clarification required;

• insufficient evidence within assignment limits;

• out of scope for this assignment.

The exact labels do not matter. They will vary by use case. What matters is that the invoking process receives a result it can interpret.

Natural language still matters. Humans need to understand the reasoning, evidence, and uncertainty. But natural language should not be the only output. If the agent returns only prose, the system has to interpret the prose to decide what happened.

Structured output and natural language serve different purposes.

The structured result lets the invoking process route the work, apply rules, detect unresolved cases, trigger review, and avoid treating uncertainty as closure. The natural-language explanation lets a human understand why the result was produced.

Predictable autonomy needs both.

Who Decides Whether the Work Is Good Enough?

Then comes acceptance criteria.

The expected outcome defines what must come back. Acceptance criteria define what must be true for that return to count as fulfilment of the assignment.

This matters because an agent can return the right kind of result and still fail the responsibility.

It may cite no evidence. It may classify a discrepancy as explained while leaving the key mismatch untouched. It may report high confidence when supporting records are incomplete. It may blur confirmed facts, assumptions, and unresolved gaps.

Acceptance criteria should be predefined and attached to the expected outcome structure. They may require judgment to evaluate, but they should not be vague after-the-fact opinions about whether the agent “did well.” In the invoice case, they should make clear what evidence must be cited, how uncertainty must be handled, and when the agent is not allowed to claim that the discrepancy has been explained.

The agent can see these criteria. It can even report how its result addresses them. But the agent should not be the final authority that decides whether its own work fulfilled the contract.

That evaluation belongs outside the agent’s self-declaration.

How Far Should the Agent Be Allowed to Continue?

Finally, the contract needs execution constraints.

Even if the responsibility is clear, the work instance is clear, the expected outcome is clear, and the acceptance criteria are clear, the agent still needs limits on how far it may continue.

An invoice investigation agent should not contact the supplier every day until someone replies. It should not keep expanding the investigation indefinitely because another record, another email thread, or another follow-up might improve confidence.

The contract must bound the pursuit of the work, not only define the work.

Execution constraints may include attempt limits, deadlines, scope limits, cost or effort limits, and return conditions. In the invoice case, this is where the contract should define how many supplier clarifications may be attempted, which records may be inspected, what cutoff matters, and where the investigation must stop.

A technical retry is not the same as another meaningful business attempt. Retrying a failed API call to retrieve invoice data is not the same as contacting the supplier again.

These distinctions need to be in the contract.

The Contract Behind Agentic Work

A sample invoice-discrepancy contract can therefore look like this.

Assignment Type

Investigate invoice and purchase-order discrepancy.

This defines the bounded responsibility the agent is designed to accept.

Work Assignment

Investigate the discrepancy between invoice INV-123 and purchase order PO-456 for supplier ABC Components, using the available invoice, purchase order, receipt records, and supplier correspondence.

This turns the responsibility into a specific piece of work in the enterprise context.

Expected Outcome

Return an investigation disposition that identifies the discrepancy, states the result category, cites evidence reviewed, records confidence or uncertainty, and lists unresolved gaps.

This tells the invoking process what kind of result must come back. The result category might be “discrepancy explained by supported evidence,” “discrepancy explained but evidence incomplete,” “supplier clarification required,” “insufficient evidence within assignment limits,” or “out of scope for this assignment.”

Acceptance Criteria

The result must identify the discrepancy, cite the records used, distinguish confirmed facts from assumptions, use a permitted result category, and avoid claiming a supported explanation when required evidence is missing.

This defines what must be true for the returned result to count as fulfilment of the assignment.

Execution Constraints

Supplier clarification may be attempted only within the permitted contact limit and time window. The assignment must return before the payment cutoff. The agent may inspect invoice, purchase-order, receipt, and supplier-correspondence records, but must not open a broader vendor-risk investigation.

This defines how far the agent may pursue the work before returning control.

None of this makes the agent’s reasoning deterministic. That is not the goal.

The goal is to make the delegation explicit. Inside the contract, the agent can still reason, investigate, adapt, compare evidence, reject one hypothesis, follow another, and produce a finding the surrounding system did not know in advance.

But the enterprise should not have to discover during execution what work the agent thought it owned, what result it thought was enough, or how long it thought it could continue.

Agentic work needs a contract.

Not because we want to remove reasoning, but because we need to know where the reasoning is allowed to operate.

I have shared the full movie link above. If you want to listen along with me, use the timestamps below, watch those moments, and experience how Raaja carries the story through music.

For the first 31 minutes of Mouna Ragam, the signature BGM does not appear at all.

When it finally comes around 31:03, it plays as a slow violin-based pathos piece for about 25 seconds. We see Divya’s indifference and Chandrakumar’s patience.

On first watch, the pain feels like Chandrakumar’s. He is the visible sufferer. Divya looks distant, even unfair.

But when we watch it again wearing Divya’s hat, the same BGM feels different. It feels like Raaja had already placed her hidden wound there.

At 35:02, Chandrakumar explains why he married her. The same BGM appears again, neatly lined up and layered.

On first watch, we feel for him. He is sincere. He is getting hurt without knowing why.

On rewatch, the music also carries Divya’s silent battle. She is not simply indifferent. Something inside her is already broken.

At 36:17, the same piece comes back with heavy strings and lasts till around 36:44.

On first watch, the heavy strings make us feel for Chandrakumar. We want to reach out to him and say, “Everything will be alright.”

On rewatch, we realise Divya is also fighting a battle inside, and Chandrakumar does not know it yet.

Then she asks for divorce.

From there, Raaja takes us into “Nilave Vaa.” Chandrakumar pours his heart out, and we also pour our hearts out with him. SPB’s voice, Raaja’s music, and the melancholic visuals make the sequence feel so heavy.

On first watch, we are still asking, “What is wrong with Divya? Why is she so indifferent?”

On rewatch, we realise she is not empty. She is trapped in a heart that is elsewhere.

Then comes that famous line: “When you touch me, I feel like a caterpillar crawling on me.”

The tabla and veena combo there is mesmerising.

On first watch, the line feels rude and harsh. Chandrakumar’s confusion becomes our confusion.

On rewatch, the music gives the line another layer. It is not just arrogance. It is unresolved hurt coming out as rejection.

At 44:04, when Divya says her heart is not with her, the same BGM comes again, very slowly, probably with piano and violin.

On first watch, we feel that something is finally going to be revealed.

On rewatch, the music still does not tell us the full story. But it gives a strange, undefined feeling. Her heart is somewhere else, with someone who is just about to be revealed. Raaja is almost telling us, “Watch carefully. Something is not right here.”

In the flashback, at 48:09, the same BGM returns, played slowly with a different instrument cluster.

Now we begin to see where the music was pointing.

At 50:24, the same BGM comes when Divya feels Manohar’s pain. At 51:03, the playful music starts.

On first watch, we may think this is Manohar’s playful sound.

On rewatch, if we look at Divya’s expression, it feels like her heart is changing from pain to happiness after seeing Manohar’s playful side.

At 53:51, a romantic piece begins and then beautifully moves into Manohar’s playful music.

On first watch, we enjoy the flutter of romance and playfulness.

On rewatch, we feel Divya’s uncomfortable acceptance that she was actually looking for him. Our heart also jumps along with that feeling.

Around this stretch, the same slow melodic BGM keeps coming and going.

On first watch, it feels like love is in the air.

On rewatch, the slowness feels like Divya slowly falling for Manohar’s charm. But it also carries a small uneasiness. Not everything is alright. Something is going to happen.

At 1:04:17, when Manohar says he wants to marry Divya, the BGM takes the scene to another level.

On first watch, we see the conflict: Manohar on one side, her father on the other.

On rewatch, the music shows her inner pull. She wants to say yes, but she is caught.

Then comes Manohar’s escape sequence. The BGM keeps building tension.

On first watch, we feel something is going to go wrong, but we may not know how it will end.

When Manohar dies, the music slows down so much that it feels like Divya’s heart is also going to stop after seeing him dead in front of her.

At 1:09:46, the shenoy is brilliant.

On first watch, it reveals that Chandrakumar gave her what she wanted.

On rewatch, that shenoy carries a strange mixture of release and pain.

Much later, at 1:45:10, when Chandrakumar is beaten up by goons, Divya relives the moment of separation with Manohar. The shenoy again plays that sogam tune.

On first watch, we feel her fear for Chandrakumar.

On rewatch, we realise an old wound has been touched again. This time, the person she is afraid of losing is Chandrakumar.

At 1:46:54, when she sees Chandrakumar fully conscious, a very slow solo guitar portrays her sigh of relief.

On first watch, it feels like relief.

On rewatch, it feels like proof that her heart has moved.

This is why I feel Mouna Ragam BGM is a story inside the story.

I do not know whether Mani Ratnam intended the film to be read fully from Divya’s point of view. But Raaja’s music certainly makes us hear her struggle.

Mani Ratnam gave us the story.

Raaja’s BGM gave us the inner story.

That is Raaja.

A few weeks back, I was talking to a relative of mine. During the conversation, he told me something that set me thinking.

“Anand, your writings look so perfect that people can immediately make out that they are written by AI. So make some silly mistakes to make them sound human.”

My first reaction was: why?

Why should I make mistakes deliberately? Why should I hide that I use AI? Why a spelling mistake to prove that I wrote the article?

That comment stayed with me. Not because I wanted to prove anything, but because it opened up a larger question. If people are going to look at AI-assisted writing with suspicion, then we also need to talk about how AI-assisted writing is actually handled.

As Vadivelu says, “Plan panni pannanum... okay?” AI-assisted writing also needs that only. You cannot take whatever AI gives and publish it directly. You have to know what you are trying to say, what you want AI to help with, and where you have to step in and correct the tone.

In a way, this was not very different from Dharumi’s situation in Thiruvilaiyadal. For those who may not know the reference, Dharumi was a poor poet in the Tamil film Thiruvilaiyadal, who got divine help from Lord Shiva to win a poetry contest in King Pandiyan’s court. He went to the court with a poem. The poem was good. Too good, maybe. And the natural question came: “Is this really yours?” That doubt did not come only from the poem. It also came from what people perceived about Dharumi.

Maybe AI-assisted writing also faces a similar perception problem. The moment people see a neat article, they may assume there was no real human process behind it. But that is exactly the perception I want to challenge. AI-assisted writing, at least the way I want to use it, is not a divine poem dropped into my hands. It goes through thinking, prompting, reviewing, rejecting, simplifying, changing, and finally checking whether it still sounds like me.

That is where the real discussion starts.

For me, writing is mainly a way to express what I think and feel. In real conversations, I may not always explain myself well. Sometimes I don’t have the time. Sometimes I don’t have the flow. Sometimes, being an introvert, I may simply keep quiet. But the thoughts are still there. The feelings are still there. The arguments are still there. They just don’t come out properly at the right time.

Writing gives me that space. It allows me to sit with a thought, turn it around, connect it with a memory, remove unnecessary drama, and finally say what I actually meant to say.

AI has helped me a lot in that process.

In the last six months, I have written nearly 25 articles. In a non-AI world, I don’t think I would have written so many. Maybe I would have written two. Maybe I would have only kept thinking about writing. The thoughts may have been there, but the distance between thinking and writing was too much. AI reduced that distance for me.

That does not mean AI is doing everything. It means AI is helping me take my scattered thoughts, examples, emotions, and half-formed sentences and put them into some shape. Earlier, many of these thoughts would have remained inside me. Now they have a better chance of coming out.

That is the good part.

But there is also a danger here.

Sometimes AI gives me a sentence that looks very polished. For one second, I feel happy. Then I read it again and think, “Ayyo, idhu naan illa.”

That is my alarm bell.

If the writing uses big English words that I would never use, it does not feel like me. If it sounds too sophisticated, it does not feel like me. If it sounds like someone giving a TED Talk after swallowing a dictionary, it definitely does not feel like me.

I prefer simple words. I like explaining things in layman terms. I like a little local flavour here and there. I don’t want my writing to suddenly sound like I became a person with TOEFL vocabs.

That is why I don’t want AI to make me sound perfect. I want it to help me express myself in my own voice, with my language limitations, and correct my mistakes. It can clean up my sentence. It can help me arrange my thought. It can point out where I am unclear. But it should not create a “me” that is actually “not me.”

Or to say it in Nithyananda style, I want the “me” to be actually me only.

This is the real tension for me. The issue is not whether AI is used or not used. The issue is what AI is being used for.

For me, this is the difference between augmentation and outsourcing. Augmentation is when AI helps me say what I already wanted to say. Outsourcing is when AI decides what I should say. If AI helps me arrange my thoughts, sharpen my examples, and express my own experience more clearly, I see that as help. But if AI invents my experience, opinion, emotion, or personality, then it is no longer just helping. It is writing on my behalf.

In Dharumi’s case, the poem came from Shiva. That was outsourcing, even if it was divine outsourcing. My situation with AI should not become that. I do not want AI Shiva to write the poem for me and ask me to simply carry it to the court. I want AI Shiva to help me shape my own rough poem better.

That difference matters.

We already accept many tools like this in other areas. We use calculators. We use spellcheck. We use GPS. We use camera correction. We use templates, grammar tools, filters, and many other things that improve our ability. We don’t usually say, “You used GPS, so you did not really reach the place.” We don’t say, “You used a calculator, so the answer is not yours.”

But writing feels different.

Maybe because language is very close to identity. When we read someone’s writing, we feel we are hearing that person’s mind. So if AI enters that space, people naturally become suspicious. I understand that.

If someone sends me a very emotional message and later I find out that every feeling in it was generated by AI, I may also feel cheated. Not because AI was used, but because the emotion was outsourced. So I don’t want to dismiss this concern.

At the same time, even in the non-AI world, is the author’s voice always as pure as we imagine? Many articles, speeches, and books go through editors, reviewers, content teams, publishers, and sometimes even ghostwriters. The final version may carry the author’s ideas, but the language may have been shaped by many other people.

Still, when we read it, we usually accept it as the author’s voice.

So maybe AI has not created this confusion newly. It has only made more people think about it. Earlier, this kind of help was available mostly to people with teams around them. Now even an ordinary person sitting at home can get help in shaping his thoughts. That is a big change.

For me, the responsibility is in how I use it.

When I edit an AI-assisted draft, I am not only checking grammar. I am checking whether it still sounds like me. Some lines may be very good, but I still change them because I would not say it that way. Sometimes AI makes a paragraph too smooth, and I have to adjust the tone till it sounds like me. Earlier I used to think editing means improving the writing. Now I feel editing also means protecting the voice.

Sometimes AI-assisted writing still gives me that Dharumi feeling. I give my rough thought, irritation, doubt, humour, memory, and confusion. AI Shiva gives me a polished sentence. I look at it and think, “Hmmm... did I write this?”

That moment is funny. But it is also serious, because I have to decide whether that sentence is really mine. Maybe the idea is mine, but the style is not. Maybe the sentence is good, but it needs to be brought back to my voice.

So no, I don’t want to add silly mistakes just to prove that a human wrote it. That feels artificial in another way. Fake mistakes are also fake only.

The goal is not to sound imperfect.

The goal is to sound recognizable and authentic.

If I use AI, I don’t want it to impersonate me. I want it to help me express myself better. I want it to help me write things that otherwise may remain stuck inside me. But I also want to make sure that when I read the final article, I don’t feel, “Idhu naan illa.”

Maybe this is the new responsibility for people like me who use AI for writing. We should not ask only, “Is this well written?” We should also ask, “Is this true to me?”

That question is more important than whether the grammar is perfect or whether the writing is sophisticated.

Because finally, I don’t want my writing to project a version of me that I don’t recognize. And worse, I don’t want to slowly start believing that this projected version is actually me.

I want it to be me.

A little clearer, maybe. A little better arranged, hopefully. But still me.

Maybe I am just Dharumi with better internet.

The Promise We Remember

Around twenty-five years ago, nanotechnology seemed to be one of those technologies that could transform people’s lives. It was discussed everywhere — in medicine, computing, manufacturing and several other areas — but the one application that caught my attention was cancer treatment.

The idea sounded almost magical.

Cancer treatment, particularly chemotherapy, could be extremely harsh because while it attacked cancer cells, healthy cells could also get caught in the crossfire. Nanotechnology seemed to offer a very different future. The promise was that extremely tiny particles could carry medicines through the bloodstream and deliver them much more precisely to the tumour, reducing the damage to the rest of the body.

And for someone like me who knew practically nothing about biology, the imagination went much further than the science probably intended. I used to picture millions of tiny nanobots floating through the bloodstream — for some inexplicable reason, they were yellow in my imagination — finding the cancer cells and attacking them with tiny spears!

It sounds funny now, but the larger expectation was not something I had invented. Around the turn of the millennium, governments and research institutions were themselves talking about nanotechnology detecting cancers when they were extremely small and making treatment much more precise. In 2000, the US government was publicly discussing a future in which nanotechnology might detect and treat tumours when they were only a few cells in size, while reducing the severe side effects of cancer treatment. By 2004, the US National Nanotechnology Initiative was discussing cancer treatments using nanostructures that could seek out malignant cells while reducing damage to surrounding healthy tissue.

So this was not merely science fiction. There was serious science behind it, and there was genuine optimism about where that science could lead.

For many years, I assumed this was one of those technologies that would gradually move from research laboratories into mainstream medicine. Yet, as the years passed, the word “nanotechnology” itself seemed to become much less visible. We continued hearing about advances in cancer treatment, but rarely in the dramatic language that surrounded nanotechnology in the late 1990s and early 2000s.

That made me wonder what had actually happened. Was the technology overpromised? Did the science fail to progress? Or did it quietly succeed in ways that were simply less spectacular than what many of us had imagined?

The answer, as I discovered, lies somewhere in between.

What Actually Arrived

Nanotechnology did make its way into medicine.

There are cancer drugs today that use very small carriers to package or transport medicines through the body. Doxil and Abraxane are two well-known examples. These approaches can change how a drug circulates, improve how it is delivered and, in some situations, reduce particular side effects. They are real treatments that are already used in clinical practice.

What did not arrive in the same way was the more ambitious picture many of us had in our heads — tiny intelligent machines travelling through our bloodstream, locating cancer cells with extraordinary precision and delivering treatment almost exclusively to them.

The progress was useful, but much more incremental than the imagination around nanotechnology had suggested.

There was another success that surprised me even more because I had never really associated it with nanotechnology.

The mRNA vaccines used during the COVID-19 pandemic relied on tiny lipid particles to protect the fragile mRNA and help deliver it into cells. The science behind these lipid nanoparticles did not suddenly appear during COVID. It was the result of decades of research, with a recent review tracing the development of these delivery systems over roughly sixty years.

Most of us never thought of this as nanotechnology. We simply called it a vaccine.

Perhaps this explains part of the mystery surrounding nanotechnology. Once a technology becomes useful enough to disappear inside a product, we stop talking about the technology itself. We do not say that we are receiving nanoscale drug-delivery technology. We say that we are receiving treatment.

In that sense, nanotechnology did not disappear. Some of it simply became invisible.

Why the Original Vision Was So Difficult

Even after giving nanotechnology full credit for what it achieved, the original ambition in cancer treatment remains only partly fulfilled.

The idea appeared straightforward when viewed from the outside. Put the medicine inside a very small carrier, inject it into the bloodstream, allow it to travel to the tumour and release the medicine there rather than everywhere else.

Unfortunately, the human body had other ideas.

Once these particles enter the bloodstream, they have to survive the body’s natural filtering and defence mechanisms. Organs such as the liver and spleen are designed to remove things that do not belong there, and a large proportion of nanoparticles may get captured before they reach the tumour. Even particles that reach the tumour face additional barriers because tumours themselves are not neat, uniform structures.

This is where the gap between the idea and reality becomes quite striking. Large reviews of nanoparticle research have found that, typically, well below one percent of an injected nanoparticle dose reaches a solid tumour. The exact significance of that number is debated — very small quantities can sometimes still produce therapeutic benefits — but it illustrates how much harder targeted delivery turned out to be than the simple picture suggests.

Some of the early experiments, particularly those using animal models, produced excellent results. Human cancers proved far more complicated. Researchers became increasingly good at creating sophisticated nanoparticles, but making them behave predictably after entering the human body was a completely different challenge. Reviews of the field have themselves pointed out that models that worked very well for demonstrating success in mice were often less useful for predicting what would happen in humans.

There were practical issues too. A treatment that works beautifully in a laboratory has to be manufactured consistently in large quantities. It has to remain stable, go through clinical trials, satisfy regulators and eventually reach patients at a cost healthcare systems can support.

So I do not think it is fair to say that nanotechnology failed. It produced genuine scientific and medical advances. But it is equally difficult to say that it transformed cancer treatment in the way people imagined twenty-five years ago.

Progress happened, but it happened more slowly, with more limited capabilities and in less spectacular ways than the early promise suggested.

Cancer Treatment Took Other Paths

This is where the story becomes far more interesting to me.

While scientists were trying to improve the precision with which medicines could be delivered, cancer treatment did not sit around waiting for nanotechnology to solve everything.

It started progressing through other approaches.

One of those was targeted therapy. Rather than concentrating entirely on how a drug could be physically carried to a tumour, researchers began identifying particular characteristics that some cancer cells depend on and developing medicines that attack those specific targets. This has now become an important part of modern cancer treatment and precision medicine.

Immunotherapy opened another path. Instead of directly attacking the cancer using a conventional drug, some treatments help the body’s own immune system recognize and fight the cancer more effectively. Several forms of immunotherapy are now used across different cancers, although they do not work for every patient or every cancer.

Chemotherapy itself has improved as well. It can still be extremely difficult, and it would be wrong to suggest that its side effects have disappeared. But doctors have become better at managing those effects, choosing treatment combinations and tailoring treatment more carefully.

Our understanding of cancer has also changed. Increasingly, doctors are not looking only at where the cancer appears in the body. They are also examining the specific characteristics of that cancer and using that information to decide which treatments might work best.

And new approaches continue to emerge. Researchers are exploring mRNA-based cancer treatments, including personalized cancer vaccines designed to help the immune system recognize features of an individual’s tumour.

The overall picture is still far from perfect, and some cancers remain extremely difficult to treat. But progress is real. In the United States, for example, the overall cancer death rate has been declining since the early 1990s, with improvements in prevention, diagnosis and treatment all contributing to that trend.

What I find fascinating is how this progress happened.

Twenty-five years ago, one exciting possibility was to make drug delivery dramatically more precise through nanotechnology. Nanotechnology did contribute to that journey, but medicine also found several other ways to pursue the same broader objective — targeted drugs, immunotherapy, better diagnosis, better understanding of cancer biology and improved treatment practices.

Medicine did not stop exploring one approach because another looked promising. It kept progressing on several fronts at the same time. That, to me, is the most interesting part of this entire story.

Which Brings Me to AI

It is difficult today to have any serious conversation about technology without artificial intelligence entering the discussion.

I am certainly not cynical about AI. In fact, I love what the technology can already do.

The research behind this very article is a good example. Without AI, researching a subject like this would have meant finding the right websites and research papers myself, reading through them one by one, trying to understand unfamiliar medical terminology, making notes, comparing different views, revisiting earlier material and eventually trying to discover the pattern hidden inside all that information.

AI has reduced that effort significantly — probably by an order of ten, and in some situations perhaps even a hundred.

That is phenomenal technology. At the same time, I did not want to simply accept whatever AI gave me. The claims in this article were checked against research papers, government publications and established medical sources. AI helped me find, compare and understand the material much faster, but the underlying sources still mattered.

And this is only one personal example. AI can already help people write software, analyse documents, summarize information, perform research, generate ideas and automate several parts of knowledge work. There is little doubt in my mind that these capabilities will continue to improve.

My concern therefore is not about AI itself. It is about what happens when one technology becomes so dominant in our thinking that almost every problem begins to acquire an AI solution.

Across customer service, software development, finance, sales, HR and operations, AI is increasingly becoming part of almost every improvement discussion.

Many of these applications make complete sense. Some will probably create enormous value.

But the nanotechnology story makes me wonder whether we should also keep looking sideways.

I should also be clear that AI and nanotechnology are not equivalent technologies. AI is much broader in its possible applications and can participate in improvements across almost every part of an enterprise. In some ways, that makes the question of fit even more important. When a technology can potentially be applied everywhere, the temptation is to assume that it should be applied everywhere.

AI as a Collaborator, Not the Only Road

An enterprise can improve in many ways — by fixing a badly designed process, modernizing an ageing system, improving data quality, integrating applications better, simplifying approvals or automating predictable work using conventional software.

AI can strengthen many of these improvements. It can help analyse processes, identify patterns, generate code, review designs and help teams move faster. In such cases, AI becomes a collaborator in the improvement rather than the improvement itself.

That is why fit for purpose matters. Not every problem becomes better simply because AI is added to it. Sometimes AI will be exactly the right tool. Sometimes a workflow, a rule, an integration or conventional automation will be the better answer.

Instead of starting with, “Where can we use AI?”, perhaps we should first ask, “What exactly are we trying to improve, and what is the most appropriate way to improve it?”

Cancer research offers a useful reminder. Nanotechnology continued to advance, but so did targeted medicines, immunotherapy, diagnostics and other approaches. Progress came from several directions at the same time.

Enterprises may need to think about AI in much the same way.

Twenty-five years from now, AI may have transformed organizations far beyond what we can imagine today. But some of the most valuable improvements may also come from less fashionable places.

That would not mean AI failed, any more than targeted therapies and immunotherapy mean nanotechnology failed.

So, whatever happened to nanotechnology?

Quite a lot, actually.

Just not everything we expected.

And perhaps that is the useful reminder for the AI age: back the breakthrough, but never stop looking for the other ways forward.

I have always seen faces in vehicles. I don’t remember exactly when this started, but some of my earliest memories are from the bus journeys I used to make between Chengalpattu and Trichy, and between Chengalpattu and Kanchipuram. We mostly travelled by private buses, and sometimes by the long-distance government buses of those days. For reasons I cannot explain even today, I would spend a considerable amount of time looking at their faces.

To me, the headlights were the eyes and the grille was the mouth. Depending on how the grille was designed, the bus could be smiling, angry, sad or occasionally just looking rather unfortunate. Some buses had grilles that were completely closed, which made them look as though they were grinning widely. I liked that expression so much that I would later stand in front of a mirror and try to reproduce it. Then there were grilles with a gap in the middle, and those buses looked like old people laughing without their teeth.

The headlights helped enormously with this imagination. In those days, they often had a black circle in the middle, meant to reduce the glare for vehicles coming from the opposite direction. I knew nothing about the purpose then; the black circles simply made the headlights look even more like eyes. Once a vehicle had eyes and a mouth, it was only natural in my little world that it should also have a personality.

My fascination wasn’t limited to buses. Lorries were equally interesting. During my childhood, Tata and Leyland were the two names I remember seeing everywhere, and I always liked the Tata lorries. Their faces looked cute to me, and they also seemed relatively quiet, which somehow fitted their personality perfectly. Leylands were a different matter. Their grilles looked like an angry person clenching his teeth, and they were noisy too. The face and the sound together were enough to convince me that these were angry vehicles. Tata, on the other hand, was the nice fellow.

Much later in life, I would learn about Tata, its history and its pioneering role in Indian industry. But apparently my relationship with the brand had begun much earlier. My childhood preference had nothing to do with engineering, business history or corporate values. I simply liked their faces.

Old movies gave me another collection of vehicle faces to study. The buses from the 1950s and 60s often had what we would call in Tamil a Siva pazham face — extraordinarily innocent and paavam. Looking at one of those buses, I could almost imagine it pleading with everyone around it, “I am paavam. Please spare me. Don’t trouble me by loading more people into me.” I wasn’t merely seeing expressions in vehicles anymore; somewhere along the way, I had started assigning characters to them as well.

There was another fascination running alongside all this: drivers. I could watch them endlessly, and it didn’t matter whether it was a car driver or a bus driver. I observed the way they sat, the way they held the steering wheel, the way they changed gears and even the way they got into the driver’s seat. At one stage, I told my mother that I wanted to become a Pallavan bus driver when I grew up. That was the level of my fascination.

We had a three-wheel cycle at home, and during vacations I discovered that it could serve a far more interesting purpose than merely being ridden around. I would turn it sideways and use one of the rear wheels as my steering wheel. I even created a makeshift gear lever using a stick near the front wheel so that I could move it back and forth. That was enough to transform the whole arrangement into my imaginary Pallavan bus, and I could spend hours during my vacations driving it. There was no bus, there were no passengers and the actual vehicle was a three-wheel cycle lying sideways, but none of these minor technical shortcomings seemed to affect the experience.

Cars naturally became part of this world too. The Ambassador was everywhere when I was growing up, and to me it had a wonderfully friendly face, with a smiling grille and beautiful eyes. The wipers fascinated me as well. As a child, I did not know that they were meant to be used when it rained, so whenever I saw them moving back and forth across the windscreen, I had my own explanation: the Ambassador was wiping the sweat off its forehead. It had obviously been working hard and needed to wipe its face once in a while.

The Premier Padmini was perhaps the cutest of them all. It looked smooth and classy, with a sweet smiling face. My grandfather had owned one before I was born, and although I had only seen photographs of it, I loved looking at them. The Jeep belonged to an entirely different species. It was bulky, sturdy and masculine, and its face reminded me of a big stern man staring directly at you. That fascination never went away either; even today, I love the way Jeeps look.

Some vehicles took my imagination in completely different directions. Mr Bean’s little car had one of the silliest faces I had ever seen, and I always found it hilarious. The old cars I saw in movies such as The Godfather produced an entirely different character in my head. With their enormously long bonnets, they looked like witches with very long noses, while the spare wheel mounted at the back somehow became the band holding the witch’s hair together. Why my mind chose to assemble a witch out of a perfectly respectable vintage automobile is something I cannot explain.

You might reasonably expect that I grew out of all this as I got older, but I didn’t. The habit simply travelled with me. More importantly, once I got married, what had begun as my own private childhood game was no longer quite so private. My wife soon discovered that I could look at a vehicle and reproduce its expression, and over the years she became a willing participant in the madness. During a drive, she would sometimes spot an interesting vehicle herself, turn towards me and ask me to make its face.

I never restricted the imitation to the grille. If the vehicle was smiling, my mouth and eyes had to smile with it; if it looked angry, the eyes and the rest of my face had to reproduce that expression too. Our daughters therefore grew up with a father who could suddenly start impersonating a truck or a car in the middle of a journey. They eventually arrived at the perfectly reasonable conclusion that their dad was a nut case.

The habit naturally continued with the cars that became part of my life. My little white Maruti Zen always looked like an angry or sad child to me; its grille simply refused to smile. The crimson-red Ritz was exactly the opposite. It had a wonderfully happy face, with the expression you have when your favourite dish has just been placed in front of you. Perhaps it was simply happy because I was driving it.

More recently, this lifelong fascination may even have interfered slightly with what was supposed to be a rational car-buying decision. I had always been fascinated by the Jeep Cherokee in the US, particularly its grille and the masculine character it gave the vehicle. When I went looking for an SUV in India, I test-drove several options from different manufacturers. The moment I saw the Kia Seltos, however, its grille reminded me of the Jeep Cherokee, and I found myself leaning towards it. The grille certainly wasn’t the only reason I bought the car, but I cannot deny that it introduced a certain amount of bias into the decision. Apparently, the boy who used to stare at bus grilles still had a vote.

Two years later came my latest addition, a grey Tata Punch EV. After all these decades of finding human expressions in vehicles, this one has presented me with something slightly different. It looks like a bug. There is a smile on its face, but it is a smile without teeth — not quite like the old toothless-person bus of my childhood, but distinctly its own expression. Every time I look at the Punch from the front, I feel that Tata’s designers stopped just a little too early. Two antennae on top would have completed the bug perfectly.

Long drives continue to be one of the best places for this pastime. There are trucks everywhere — Tata, Leyland, Eicher and many others — and I still find myself looking at their faces and assigning personalities to them. Over the years, I have even watched those personalities change. The Leyland trucks that frightened me as a child don’t seem quite as angry anymore. As the designs changed, some seemed to acquire smiling faces while others became almost expressionless. I couldn’t tell you which model changed in which year, but somewhere deep inside I remember the character changing. The angry man who used to come towards me clenching his teeth seems to have calmed down over the years.

Nobody taught me this game. It was entirely my own private invention, and what surprises me is not that I did something like this as a child, but that I never really stopped doing it. More than four decades later, a long highway journey still gives me an endless procession of characters to observe. Some vehicles look happy, some angry, some stern, some paavam and some appear to have no opinion about life whatsoever. Every now and then, one comes along with an expression interesting enough for my wife to turn towards me and ask me to reproduce it, which I invariably do, much to the continuing amusement — and occasional embarrassment — of my family.

I don’t think there is a profound lesson hiding behind any of this. I don’t consciously look at vehicle faces because I am trying to preserve the child in me, practise mindfulness or rediscover some forgotten simplicity of life. I still do it for exactly the same reason I did it all those years ago: I enjoy it. Through different cities, cars and stages of life, this completely unnecessary little pastime has simply travelled along with me.

And somewhere on the road ahead, there will inevitably be another bus coming towards me with a peculiar grille. It probably isn’t looking at me, but after all these years, I am still looking back.

One of the more difficult questions I encountered while thinking through enterprise agents came from a supplier invoice discrepancy.

The task we had in mind appeared straightforward. An agent would examine the discrepancy, contact the supplier when clarification was needed, evaluate the response and return its findings to the business workflow.

Then we considered a slightly different response. Suppose the supplier acknowledges the discrepancy and proposes a revised amount. The agent can evaluate that amount. But should it also be allowed to accept it?

The agent has been asked to investigate the discrepancy. Accepting a revised amount might appear to be a reasonable way to complete that goal. It may even produce the right commercial outcome. Yet it also creates a commitment that the enterprise may never have intended the agent to make.

The problem is not simply whether the agent is intelligent enough to respond. It is whether the words investigate the discrepancy have silently given it more responsibility than the surrounding system was designed to surrender.

That question led me to a broader conclusion. We often describe agents as if they were digital colleagues who can be assigned a goal and trusted to work out what the assignment means. Enterprise agents need to be treated differently.

They are software systems. Their responsibilities, authority, interfaces and failure behaviour have to be engineered.

What Makes the Component an Agent?

Before deciding where an agent’s authority should end, we need to be clear about what makes the component an agent in the first place.

Consider a conventional application that follows a prescribed sequence. It retrieves an invoice, sends a standard request for supporting documents, receives the supplier’s response, summarises it and sends the material for review. AI may help compose the message or interpret the response. That makes the application AI-assisted, but not necessarily agentic.

Now change the behaviour.

The component examines the supplier’s response and notices that it does not explain the additional charge. It decides what clarification is still needed, requests further evidence, evaluates what comes back and adjusts its investigation. The next action depends on what it discovers during execution.

That is the distinction I find useful:

An AI agent is a software component that uses AI to select and adapt actions toward a goal, based on information encountered during execution.

The important part is not merely that AI is present. It is that AI participates in selecting and adapting the actions that move the task forward.

An LLM that classifies an invoice may be an AI-enabled capability. An LLM that drafts a supplier email may be assisting a person or a workflow. A component that decides what evidence to retrieve, discovers a gap, asks a follow-up question and changes its approach is behaving agentically.

The distinction is about how the work progresses, not whether the software has been given a human-sounding role.

Agency Is Not Autonomy

The supplier example exposed a second distinction that I believe is even more important.

Agency describes how a component pursues a goal. Autonomy describes the authority delegated to it while doing so.

The investigation component is an agent because it selects and adapts actions based on the evidence it encounters. Whether it may accept a revised amount is a separate decision about autonomy.

One enterprise may allow the agent to gather evidence, evaluate the revised amount and return a recommendation. The workflow then routes the case for human validation. Another enterprise may eventually permit the agent to accept certain revisions under defined conditions.

The component is agentic in both arrangements. What changes is what it may decide and cause.

This also explains why a bounded agent is not simply a copilot with the human removed. In a copilot arrangement, AI may analyse the situation and propose a next action, while the human continues to choose how the task progresses. In an agentic arrangement, the component itself selects and adapts at least some of the actions that progress its assigned task.

Human involvement can exist in either design. A human may approve the agent’s final recommendation without selecting every investigative action the agent took to reach it.

The deeper question is therefore not whether a human appears somewhere in the process. It is who selects and adapts the actions that progress the task, and what authority accompanies that responsibility.

The Workflow and the Agent Own Different Progress

This distinction helped resolve another source of confusion: the word orchestration.

At the enterprise-process layer, a workflow may own the lifecycle of the invoice. It records that a discrepancy has been identified, invokes an investigation, waits for its result, routes the evidence for validation and determines whether the invoice proceeds, remains blocked or is escalated.

Inside one step of that workflow, an agent may own the investigation. It decides what evidence is missing, which permitted capability to use, whether the supplier’s response answers the question and whether another follow-up is justified.

Both are orchestrating work, but they are not orchestrating the same thing.

The workflow owns progression of the business process. The agent owns adaptive execution toward a bounded goal inside that process.

This separation allows the agent to be genuinely agentic without quietly inheriting the surrounding business process. It may choose its investigative path, consult governed specialist agents and revise its approach. When it reaches a conclusion, an uncertainty or an execution limit, it returns control to the workflow.

The result from the agent may still influence what the workflow does next. That does not require the agent to own the transition. The workflow can evaluate the returned result through explicit business rules, policy checks, approval thresholds or human validation.

The two layers also own different state. The agent needs working context for the investigation: the supplier’s responses, evidence gathered, questions already asked and conclusions reached. The workflow owns business state: whether the invoice is under investigation, awaiting validation, approved, rejected or escalated.

Those states may be stored together or separately. The architectural issue is who is entitled to change them and what each change means.

The Boundary Must Be Engineered

Once we separate these responsibilities, the phrase investigate the discrepancy is no longer sufficient.

The invoking workflow should tell the agent what work has been entrusted to it, what actions it may take, what outcome it must return and when it must give control back.

For the supplier discrepancy, the agent may be permitted to identify missing evidence, request clarification through an approved communication mechanism, evaluate the response and return its findings. It may be explicitly prohibited from negotiating commercial terms, accepting a supplier proposal, approving the invoice or posting payment.

The return contract matters just as much. A response saying the discrepancy is resolved tells the workflow too little. What evidence was obtained? What did the agent conclude from it? What remains uncertain? Was the investigation completed, or did it stop because a time or retry limit was reached?

These are not documentation details added after the agent is built. They give the assignment its concrete meaning.

The agent can choose how to pursue the investigation within that contract. It cannot redefine successful completion to include authority it was never given.

This resembles the discipline we already apply when designing services. A service has a cohesive responsibility, an explicit interface, managed dependencies, defined outcomes and known failure behaviour. I find that analogy useful for agents as well.

It does not mean every agent must be deployed as a separate microservice. Related agents may be co-located, and an agent service may expose them through common infrastructure. The useful part of the analogy is the engineering discipline: the component’s responsibility should be explainable, its contract should be precise and its failure should be contained.

A precise contract gives us something to enforce. The surrounding system must still enforce it.

We could tell the investigation agent: You may request evidence, but you must not negotiate. That instruction communicates the intended boundary. Yet if the agent has access to a general-purpose email tool, it can still compose and send a message that crosses it.

A request for supporting documents and an offer to accept a lower amount both use email. Checking whether the agent is allowed to send email does not distinguish between them.

This is where prompts and lists of dos and don’ts reach their limit. Natural-language instructions are interpreted by the same probabilistic system whose behaviour we are trying to constrain. They can guide the agent, but they should not be the only control protecting a consequential boundary.

For this task, the system could expose a narrower capability: request supplier evidence. The agent determines what clarification is needed and selects an approved request type. The application constructs the communication from controlled templates and validated fields. If the required communication falls outside those supported operations, the agent returns the case to the workflow.

Even the template needs care. An unrestricted comments field can quietly recreate the freedom that the controlled interface was intended to remove.

The general principle is simple. The capabilities available to an agent should reflect the authority it has actually received. Tool access answers whether the agent can reach a capability. The operation exposed through that capability determines what it can cause.

Delegation Must Preserve the Boundary

The same principle applies when one agent invokes another.

Suppose the investigation agent asks a supplier-communication specialist to obtain clarification. That specialist may conduct several permitted exchanges, examine the replies and determine whether more evidence is needed. The investigation agent then evaluates the material alongside the rest of the case.

This is still bounded agentic execution. But access to specialist agents must be governed, and delegation cannot expand the original authority.

If the investigation agent has no authority to negotiate, it cannot create that authority by delegating to a specialist that happens to know how to negotiate. The invoked agent’s available goal, actions and tools must remain within both its predefined responsibility and the authority carried by the specific assignment.

The contract between the agents also needs to be concrete. If the specialist is expected to return two supporting documents, a reassuring summary is not an adequate result. It should return the documents, the findings, unresolved gaps and the status of the attempt.

Retries and timeouts belong in that contract as well. An agent should not keep contacting the supplier indefinitely. If it reaches the permitted number of attempts or the response deadline passes, it returns an incomplete outcome for escalation.

Restarting the same task for the same invoice without new information should not silently reset those limits. Fresh information may justify another attempt, but the decision to reopen execution belongs to the surrounding control logic—the workflow or invoking application that owns the case—not to the invoked agent that exhausted its assignment.

Delegation is therefore not simply agent-to-agent communication. It is the transfer of a specific task under inherited constraints, with an expected result and a defined return of control.

Engineering the Autonomy

Authority is not the only boundary an agent needs. The execution itself also needs to be contained.

Suppose several agents are drawn as separate components but run inside the same unrestricted runtime. One of them enters a loop, repeatedly calls tools, accumulates context or launches more work than expected. It can consume the memory, processing capacity or external-service quota needed by every other agent in that service.

If the same runtime also hosts the business application, the failure can spread further. An investigation agent that goes rogue should not create a denial of service for invoice processing.

This is why I prefer agent execution to have its own managed runtime space and to be invoked through explicit interfaces. An agent gateway may govern discovery, identity, access and routing. An agent service may host the execution environment and expose stable APIs to workflows, user interfaces, scheduled jobs and business applications.

Again, this does not require one deployment for every agent. Co-location can be entirely reasonable. But logical separation is not resource isolation. Separate instructions and separate conversation histories do not impose limits on duration, concurrency, memory consumption or downstream calls.

Those limits need runtime enforcement. The architecture should be able to cancel work, contain failure, prevent uncontrolled spawning, preserve an execution record and protect neighbouring workloads.

These concerns are familiar because the fundamentals of software engineering have not disappeared. New AI capabilities change what a component can do and how its path unfolds. They do not remove the need to define interfaces, manage state, control resources, observe execution and design for failure.

The supplier example began with a seemingly small question: may the agent accept a revised amount?

Following that question exposes most of the architecture around an enterprise agent.

We need to know what makes the component agentic. We need to separate its agency from the autonomy delegated to it. We need to distinguish progress inside the assigned goal from progression of the surrounding business process. We need a contract that defines the responsibility and a runtime that can enforce the boundary. If the agent delegates, that boundary must survive the handoff.

None of this requires us to make the agent less intelligent or prescribe every step in advance.

The investigation agent can still interpret ambiguous evidence, choose among permitted capabilities, change its approach, ask follow-up questions and coordinate governed specialist agents. That adaptive behaviour is why we introduced an agent in the first place.

But the freedom to choose a path does not establish autonomy to take every action along it.

An enterprise may increase that autonomy over time. It might begin with human validation of every recommendation, observe the system’s behaviour and later permit specific actions under defined conditions. That is a governance decision. The architecture’s job is to make each decision explicit and enforceable.

Some permissions may expand. Others—especially authority over consequential business-process progression—may remain with the surrounding system.

This is what it means to treat agents as systems rather than colleagues. We define the responsibility, the contract, the available actions, the state ownership, the execution limits, the escalation path and the conditions under which control returns.

The autonomy we see is the behaviour. The predictability we need has to be engineered.

The Rocket Ships Among Us

The moment some people enter a vehicle in India, something seems to happen to them. They suddenly feel that they own the road and that the vehicle they are driving is not a car, bike or auto but a rocket ship. Rules don’t matter much after that. Traffic etiquette doesn’t matter either. All that matters is getting to the destination by somehow travelling through space-time and reaching there in zero seconds — or, even better, before they have left home!

Once that becomes the objective, everything else becomes negotiable. Pavements, shoulders, the wrong side of the road and microscopic gaps between vehicles all become perfectly legitimate driving surfaces. If it were physically possible, I suspect some motorists would drive over us as well. The worst affected are probably pedestrians, for whom pavements and zebra crossings offer no particular guarantee of safety. We Indians are remarkably good at adjusting to everything around us, but should we have to keep adjusting to indiscipline on our roads forever?

Cars, at least in my experience, are still somewhat manageable. But it is the two-wheelers that really keep you on your toes. They can overtake you from the left or right, squeeze into a gap barely wider than their handlebar and then look offended that you did not anticipate their arrival. Whether they are following the traffic rules or breaking every one of them, somehow it remains your responsibility to make space.

Sometimes, You Just Get Lucky

I used to love driving. For a very long time, it was a passion for me, but the explosion in traffic volume and increasing indiscipline on our roads have slowly taken some of that pleasure away. Every time I get into the car today, I seem to be doing several jobs simultaneously: driving my own car, predicting what the bike beside me might do, watching the auto that has somehow invented a third lane, checking whether somebody is coming towards me on my side of the road, anticipating the pedestrian who has chosen that exact moment to cross, and looking out for buffaloes, cows and dogs that can suddenly decide to participate in traffic without warning. Somewhere in the middle of all this, I also need to maintain sufficient vocabulary to swear at everybody involved. Fortunately, after all these years of driving, I have built up a fairly extensive vocabulary. Driving has become a full-stack activity requiring concentration, anticipation, reflexes and occasionally a degree of divine intervention.

Over nearly three decades of driving, I have had enough near misses to know that this is not merely irritating. One incident that remains vividly in my memory happened many years ago when I was driving my Santro from Chennai to Bangalore. Somewhere near Ranipet, I was travelling at around 90 kmph when a TVS 50 suddenly entered the highway from my right. The rider saw my car approaching, appeared completely unsure of what to do and began moving zigzag across the highway.

At that speed, I had seconds to react, very little room to manoeuvre and absolutely no idea which direction he would choose next. Even today, I don’t know exactly how I managed to avoid hitting him. Definitely divine intervention! There have been many such incidents and interventions over the years, both on city roads and highways. On particularly bad days, reaching home unscathed genuinely feels like an achievement. That should never become our definition of a successful commute.

We Know the Sensible Solutions

It is not as though we don’t know what needs to be done. We have cameras, fines and traffic police, although enforcement could certainly be much stricter and more consistent. We need better policing, better road design and, most importantly, better driver education and discipline. That education has to begin at school and at home, because traffic rules should not be something we follow only when a policeman is watching. The road is a shared public space, and our behaviour can put somebody else’s life at risk.

But most of these are long-term solutions. Education takes years, cultural change takes longer, and enforcement depends on somebody noticing the offence and eventually imposing a consequence. As a common citizen driving today, however, I have a more immediate requirement. If somebody comes towards me on the wrong side of the road, I don’t want him to discover road discipline sometime in 2047.

I want immediate feedback.

And since nobody seems to be offering it, I have decided to design the solution myself.

The National Traffic Reform Programme

After considerable thought and absolutely no consultation with anybody qualified to comment on the subject, I have developed what I believe could transform Indian roads: the National Traffic Reform Programme — NTRP.

I am a big fan of our Prime Minister, and I have taken a leaf out of his book by giving my programme an acronym. There is something wonderfully official about an idea once it acquires a few capital letters. Give it an acronym, launch a portal and create an app, and suddenly it feels like national policy.

So NTRP was born.

The principle behind NTRP is simple: instead of waiting decades for road behaviour to change, the road itself should provide immediate feedback.

My first proposal is a retractable mechanical arm mounted at the front of every car. When somebody unnecessarily blocks the road, stops diagonally in the middle of traffic or decides that this is the ideal location to conduct a conversation with another motorist, the arm extends and gently clears the obstruction. The word gently is important. We are, after all, a civilised society.

Much of the interesting activity on Indian roads, however, happens beside the car. So we need two additional retractable arms, one on either side, each fitted with a large boxing glove. A biker begins squeezing into a gap that doesn’t exist? The glove emerges politely. Someone comes towards you on the wrong side and expects you to move out of his way? The glove becomes visible. I suspect we may not even need physical contact. Merely seeing a boxing glove slowly emerge from the side of a car should be enough to awaken considerable civic responsibility.

Naturally, the system could have different settings depending on the seriousness of the offence: Gentle Reminder, Strong Suggestion, and You Really Shouldn’t Have Done That.

High Beams, Horns and Other Forms of Torture

NTRP also needs to address traffic etiquette. Take high beams. Some motorists seem to believe that headlights are meant to conduct an ophthalmological examination of every driver approaching from the opposite direction. For them, I propose Automated High-Beam Reflection Technology — AHBRT, which safely gives the offending motorist a symbolic taste of his own brilliance. My original idea involved a sharply focused counter-light, but two blinded motorists approaching each other at speed presented certain minor implementation challenges.

Then there is unnecessary honking. Fifty vehicles are waiting at a red signal, there is nowhere anybody can go, and yet somebody behind starts honking. Does he expect the forty-nine vehicles ahead to recognise his importance and collectively evaporate? NTRP therefore includes an Automated Horn Reciprocity System (AHRS): every unnecessary horn is played back inside the offending vehicle for twice the duration. I expect our most enthusiastic honkers to discover inner peace rather quickly.

These ideas are useful, but I still felt NTRP needed one definitive mechanism for serious offenders.

That was when I remembered James Bond.

The James Bond Solution

Those old James Bond cars were magnificent. Bond would be driving along quite normally, casually flip a switch on the dashboard and suddenly a perfectly innocent-looking car would reveal capabilities nobody outside Q Branch knew existed.

That is precisely what Indian traffic needs.

Under NTRP, every car will have a concealed compartment built into the front. Somewhere on the dashboard will be a switch protected by a transparent cover, so nobody accidentally activates the system while trying to turn on the air-conditioning.

Imagine someone coming towards you on the wrong side. He has already decided that you will move left and make space for him because that is what everybody has always done. You see him, he sees you, and instead of honking or shouting, you calmly lift the transparent cover and flip the switch.

A small panel in the front of the car slowly opens, and from inside emerges a gun.

Before anybody calls the police, let me clarify that there are no bullets in this gun. I may have spent nearly three decades getting irritated with Indian motorists, but I am not homicidal.

The gun fires a dart.

And the dart contains a diarrhoea shot.

Yes, you read that right. A diarrhoea shot!

Now we have immediate feedback.

Someone comes down the wrong side? Dart. Someone jumps a red signal? Dart. A biker decides that the pavement is an excellent alternative to the congested road? Dart. Someone cuts across three lanes without warning because missing a U-turn apparently threatens the future of his entire family? Dart.

There is no road rage or argument through the window. The NTRP simply administers immediate behavioural feedback, after which both motorists can continue towards their respective destinations, although one of them may shortly have to modify his.

Because the James Bond launcher only covers what is in front of the car, every certified law-abiding citizen will also receive a handheld version using exactly the same darts. Pedestrians, considering everything they have endured on our roads, should certainly qualify for the compact version.

After the first few weeks, I suspect we may not even need to fire very often. A biker approaches from the wrong side, notices the little panel opening in front of my car and suddenly the Motor Vehicles Act flashes before his eyes. Civic responsibility awakens somewhere deep inside him, and he executes the most disciplined U-turn in the history of Indian motoring.

Forget BS7. India Needs BS99

A national programme as important as NTRP cannot depend on automobile manufacturers implementing these capabilities however they please. We need standards.

Now, before the automobile experts come after me, I know that Bharat Stage standards are meant for vehicle emissions. But looking at the way we drive, emissions are hardly the only thing that needs regulating. So I am borrowing the nomenclature.

We already had BS3, BS4 and BS6. Given the magnitude of our traffic problem, forget BS7 and BS8. For NTRP, I propose BS99 — the Bharat Stage standard that has absolutely nothing to do with emissions and everything to do with surviving Indian traffic.

Under BS99, every new vehicle will support the complete NTRP specification: traffic-clearing arm, side-mounted boxing gloves, AHBRT, AHRS and the concealed diarrhoea-dart launcher. Manufacturers can still differentiate their variants. The base model might get a manually aimed single-shot launcher, while the top-end version gets a camera-assisted system with automatic violation detection.

Automobile reviews will become much more interesting. Along with steering feedback, suspension, rear-seat comfort and mileage, reviewers can tell us how quickly the launcher acquires a wrong-side biker. Used-car advertisements will change too: Single owner. Full service history. BS99 compliant. Boxing gloves recently replaced. Only 17 darts fired.

Punishment Must Fit the Crime

Obviously, even diarrhoea cannot be administered without standards. The strength of the shot must correspond to the seriousness of the violation. A minor offence might produce one hour of digestive uncertainty. Wrong-side driving could attract four hours, signal jumping perhaps six, and driving on the pavement twelve.

If somebody manages to drive on the wrong side while simultaneously talking on the phone and honking continuously, the BS99 system will automatically select the premium formulation. At that point, my only advice to the gentleman would be to locate a restroom immediately. Repeat offenders would naturally qualify for enhanced dosage under the NTRP Habitual Offender Scheme.

Within a month, I genuinely believe Chennai traffic could become Scandinavian. People would stop at zebra crossings, motorcycles would remain inside lanes, pavements would return to pedestrians, indicators would be rediscovered and red traffic lights would finally acquire their intended meaning. Google Maps might even display a notification nobody in India has ever encountered before: “Unusually disciplined traffic ahead.”

Unfortunately, I Found an Architectural Problem

Just when I was beginning to feel rather proud of NTRP, my architect instincts interfered. Who decides who has committed the violation? From the perspective of a car driver, the biker is usually wrong. From the biker’s perspective, the car driver is probably wrong. The auto driver believes both are wrong, while the pedestrian has legitimate reasons to believe that everyone operating anything with an engine is wrong.

Imagine a typical Chennai junction. A biker cuts in front of me and I administer immediate NTRP feedback. He believes I didn’t give him enough space and fires a dart back at me. The auto driver behind us thinks both of us have blocked him and joins the programme. The pedestrian whom all three of us nearly hit now decides that justice requires intervention from his side as well. Within fifteen minutes, everybody at the junction has administered diarrhoea shots to everybody else.

The road becomes completely empty, but the nearest public toilet now has a two-kilometre queue. We have successfully solved India’s traffic-congestion problem and created a national public-toilet infrastructure crisis.

As someone who has spent much of my professional life around technology and architecture, I find this strangely familiar. In software systems, you identify a performance bottleneck, optimise it beautifully and then discover that you have merely moved the bottleneck somewhere else. Under NTRP, road throughput becomes spectacular while the toilets crash. We haven’t eliminated the queue. We have simply moved it.

NTRP Needs Governance

Clearly, we need governance. There will have to be Aadhaar-linked launchers, dashcam evidence, dosage standards, firing limits, audit trails and naturally an NTRP app. Disputes will inevitably arise. Somebody will insist that he wasn’t driving on the wrong side but was merely temporarily directionally challenged. Another will claim that the traffic signal was somewhere between orange and red. A third will argue that riding on the pavement was unavoidable because the road was congested.

Clearly, we need an appeals body. I therefore propose the National Diarrhoea Tribunal — NDT.

Once again, I must acknowledge the inspiration provided by our beloved Prime Minister. NTRP, NDT, AHBRT, AHRS and BS99 already sound sufficiently official that I am beginning to wonder whether I should prepare a Cabinet note.

And once NTRP becomes successful, our entrepreneurial abilities will take over. Modified launchers, high-strength diarrhoea darts and counterfeit NTRP ammunition will inevitably appear. My beautifully simple solution to Indian traffic will, within months, have evolved into an enormous ecosystem involving regulators, apps, tribunals, certification bodies and black-market diarrhoea ammunition.

At which point, I suppose, we can safely declare the programme mature.

But Why Are We in Such a Hurry?

Underneath all this absurdity is something that genuinely worries me. People routinely risk their own lives and somebody else’s merely to save a few seconds. We see motorists squeeze dangerously through traffic, change lanes repeatedly, jump signals and race ahead as though every second matters. Quite often, after watching somebody perform all these manoeuvres and disappear into the distance, I reach the next traffic signal and find the same person waiting beside me.

All that weaving, aggression, honking and risk — and what did he gain? Perhaps thirty seconds. Quite often, nothing at all.

That takes me back to where this story began. Why does entering a vehicle suddenly make us believe that time has to be compressed? Why does reaching somewhere five minutes earlier become important enough to justify frightening a pedestrian, squeezing another vehicle off the road or putting somebody’s life at risk?

The problem on our roads is not simply infrastructure or policing. Somewhere along the way, we seem to have lost patience, consideration and the basic understanding that the person beside us has exactly the same right to reach home safely as we do. Better enforcement, road design and education will help, but ultimately some amount of discipline has to come from within us as well.

Until that happens, I suppose I will continue doing what millions of Indian motorists do every day: drive defensively, anticipate what others might do, occasionally swear, survive the journey and wonder why everybody is in such a hurry.

And if you happen to come towards me on the wrong side of the road and notice my hand slowly moving towards that little transparent cover on the dashboard, perhaps you should reconsider your choices.

After all, BS99 may still be awaiting government approval.

But the idea is ready.

So turn around.

And, just to be on the safe side, make a mental note of where the nearest restroom is.

Disclaimer

BS99, NTRP, NDT, AHBRT, AHRS, diarrhoea darts, boxing gloves, traffic-clearing arms and every other ridiculous invention in this article exist entirely in my imagination. This is satire, not a proposal to hurt, punish or take revenge on anyone. Please don’t build any of them. Drive safely, follow the rules and let everyone else get home safely too.

Over three months, I used an AI assistant to help develop nearly 190 user stories for a platform I have been architecting. The specifications were already substantial. They described the platform’s components, responsibilities, interfaces, standards and non-functional requirements. The purpose of the exercise was to turn that material into work that development teams could build.

Decisions that appeared settled in the specifications had to be reconsidered when we examined how they would be implemented. Assumptions that were reasonable within one component became problematic when another component depended on them. Standards that looked appropriate at the platform level produced unacceptable consequences for particular teams. In other cases, the stories introduced decisions that had no basis in the specifications at all.

None of this changed my understanding that specifications and implementation serve different purposes. Architects already know that specifications cannot contain every implementation decision and that detailed questions will emerge when a design is translated into buildable work.

What became much more visible to me was the function required to manage what happens when those questions emerge.

Someone had to recognize when a question was local to a story and when it had wider architectural consequences. Someone had to hold enough of the system in view to understand those consequences, remember why earlier decisions had been made, and determine whether the story, the specification or an architectural standard needed to change.

I refer to this function as design authority. It may already exist in many organizations, exercised by an architect, technical lead, senior developer or a group of people. But it is often hidden inside activities such as story development and technical clarification, even though the decisions being made there can affect the architecture of the system.

The experience also made me think more carefully about the capabilities required to perform this function. It is not enough simply to assign someone responsibility for resolving architectural questions. The function requires a level of system context, continuity, judgment and authority that organizations need to develop deliberately.

AI makes this increasingly important. In this work, AI helped not only to develop the stories but also to review them against specifications, standards and architectural decisions. It could identify genuine tensions and suggest possible resolutions. But interpreting those findings still required design authority.

Specifications are communication artifacts

Specifications allow architects, product teams and developers to establish a shared understanding of a system before all its implementation details are known. They describe capabilities, responsibilities, boundaries, interactions and constraints at a level that allows the system to be discussed as a whole.

Turning that material into buildable work necessarily involves interpretation. Capabilities have to be divided into buildable units. Interfaces have to be made concrete. Dependencies have to be sequenced. Error conditions, initialization paths and operational states have to be considered. Decisions that were left open at specification time eventually have to be made.

This process is sometimes treated as backlog preparation: an administrative step between architecture and development. I think that understates what is actually happening. Developing a story often requires us to explore how a capability will work in enough detail to test whether the original specification still holds.

The specification shapes the stories, while the stories can also test and refine the specification.

Several incidents during the development of the platform backlog made this visible.

When the how changes an earlier decision

We needed to establish a foundational tooling standard that would influence multiple services and future migrations. We evaluated the available choices, made a decision and documented it in the architecture.

Five days later, the first group of stories that had to use the standard exposed a mismatch with the actual authoring pattern. Based on that discovery, we reconsidered the decision and moved towards a custom alternative.

Seven days after that, another set of stories exposed a different issue. The custom approach was beginning to recreate capabilities that the original tool already provided. We returned to the original decision, although our reasons for choosing it were now different and better informed.

Viewed only as a sequence of changes, this could appear indecisive. In practice, each revision responded to a constraint that became visible only when a different part of the system had to use the standard. Our understanding of what the standard needed to support had become more complete.

This was not implementation departing from architecture. It was implementation-level exploration improving an architectural decision. The what and the how were influencing each other.

Architecture across the system lifecycle

A different kind of issue emerged while we were developing stories for the notification capability. The component needed to resolve a role into the users holding that role and then dispatch messages to them.

The individual behaviour was straightforward, but the story raised a question about a newly deployed platform. Where would the first users come from?

The platform’s seed data created services, roles, permissions and configuration. It did not create real people. As a result, every role-to-user lookup on a fresh installation would return an empty list. Notifications could be dispatched successfully from the component’s perspective while reaching nobody.

The permissions specification described how permissions would work. The notification specification described how recipients would be resolved. The seeding process correctly avoided inventing real users. What none of them defined was how the platform would move from an initialized technical state to an operational state containing its first users, or which capability owned that transition.

This was not simply an unstated assumption inside one specification. It was an unresolved part of the platform’s runtime architecture. It concerned sequencing and ownership across several modules during a particular stage in the system lifecycle.

Component specifications tend to describe steady-state responsibilities well. Story development often exposes the transitions around that steady state: initialization, deployment, migration, recovery and retirement. Those transitions may not belong to a single module, but they still require architectural decisions.

Architecture between modules and organizations

Another incident concerned how the platform’s user interface would be composed. An architectural standard written several months earlier stated that UI modules would be bundled with a common shell and released as a single artifact. The standard had been documented and referenced by several stories.

While developing a later group of UI stories, we followed the decision through to a specific customer-facing product and its release process. The consequence was that every platform enhancement added to the shared shell would require the product to redeploy, even when nothing in the product had changed.

The original rule was reasonable when considered as a mechanism for simplifying UI composition. Its cost became apparent only when the design was placed in the context of a team operating on its own delivery schedule.

We retired the rule and updated the affected parts of the architecture documentation.

The important boundary in this case was not only between software components. It was also between the platform and the teams consuming it. The technical design created an operational dependency across organizational boundaries. That dependency became visible only when the story connected an architectural standard to the release process of a particular team.

Together, these incidents show the different kinds of architectural questions that can surface when specifications are developed into buildable work. The question then becomes who is equipped to recognize and resolve them.

Design authority during story development

I use the term design authority for the function that carries this responsibility.

Design authority is not necessarily a job title. It may be exercised by an architect, a technical lead, a senior developer or a group of people with explicitly assigned responsibilities. What matters is not the title but whether the people performing the function have the capabilities required to make decisions at the level of the system rather than only within an individual story or component.

The first of these is breadth. Design authority needs a bird’s-eye view of the system described by the specifications and an understanding of how decisions within one component or feature interact with others. The notification issue could not be understood purely from the notification component, just as the UI composition issue could not be understood purely from the shell.

It also requires continuity. The significance of an architectural decision often depends on why it was made, what alternatives were considered and what conditions existed at the time. A standard read in isolation may appear absolute when it was actually a response to a particular constraint. When circumstances change, someone needs enough continuity with the architecture to recognize the difference.

Standards custody is closely related. Design authority needs to know which architectural rules and decision records genuinely govern the system, how they relate to one another and when a proposed decision conflicts with them. This becomes particularly important when AI participates in story development and review, because a plausible reference to a standard is not the same as an actual standard.

The function also requires lifecycle awareness. Architecture is experienced not only through component interactions at runtime but through initialization, deployment, migration, operations and the ways in which other teams consume the platform. Some questions become visible only when the system is viewed across those stages.

Finally, design authority requires contextual judgment, authority and accountability. Someone has to distinguish a local implementation choice from a decision with wider architectural consequences. When a conflict emerges, that person or group must be able to determine whether the story should change, whether the specification or standard should be revised, or whether an exception is justified.

These capabilities cannot simply be assumed to exist because responsibility has been assigned. Developers should develop architectural capability, and AI can help them explore systems and decisions in ways that were previously much harder. But a developer with only a few years of industry experience may not yet have had the opportunity to build a system-wide perspective, follow architectural decisions over time or experience their consequences across deployment and operations. This is a question of exposure and context, not simply individual capability.

Experience alone does not automatically create design authority either. Organizations need to understand which capabilities the function requires, develop them deliberately and ensure that they are present when architectural questions emerge.

This function also needs to be accessible while the specification is being turned into buildable work. Review only at specification approval is too early for questions that have not yet emerged, while review only at the code stage may come after a story has already embedded the wrong decision.

This does not mean that an architect must write or approve every story. Teams need a clear way to identify architectural questions during story development and bring them to someone who holds the relevant context.

AI as an assistant to design authority

AI played more than one role in this work. It helped draft the stories, but it also helped review them against the architectural specifications, standards and decision records.

That review added significant value. It found genuine omissions and raised conflicts that had not been captured in the original story drafts. Some findings could be resolved through clarification. Others required me to return to the story, reconsider the design and change the proposed approach.

The assistant was particularly useful for examining a large body of stories with greater consistency than a person could easily maintain. It could compare a story with documented standards, identify an apparent deviation and suggest alternatives. Used in this way, AI extended the reach of architectural review.

However, the review output still required judgment. A red flag could mean that the story was wrong, that the architectural standard was outdated, that the specification had left something unresolved or that the deviation was justified by context. The assistant could identify the tension and propose responses, but design authority still had to decide what the tension meant.

Two incidents illustrated this distinction.

In one batch of drafts, several stories referred to an architectural rule prohibiting a particular kind of cross-entity database join. The rule sounded credible, fitted the style of our other standards and appeared consistently across multiple sessions.

The rule did not exist.

The actual principle was narrower and concerned repository ownership rather than join semantics. The generated rule often produced an outcome similar to the real principle, which was why it survived for some time without attracting attention. Familiarity with the specifications eventually exposed the difference.

The assistant had not produced an obviously absurd answer. It had produced a plausible extension of the material around it. Had we accepted it without checking its provenance, repetition could eventually have turned a generated interpretation into what appeared to be an established architectural rule.

In another session, we were considering whether to divide a foundational story into two. The assistant argued against the split because both parts still had to be delivered sequentially. If the objective was parallel delivery, its reasoning was sound.

Parallelism, however, was not the relevant concern. Keeping the story intact created dependencies between operations in different features that did not actually depend on one another. Splitting it removed those false relationships and made the real sequence of work clearer.

The assistant had reasoned correctly within the immediate framing of the question. Reaching the appropriate decision required a wider view of the system’s dependency structure.

These examples clarify the division of responsibility. AI can surface inconsistencies, examine alternatives and extend the coverage of architectural review. Design authority interprets those findings and makes decisions in the context of the whole system.

Making the boundary visible

The boundary between what and how will exist whether an organization acknowledges it or not. The practical question is whether the decisions made there are visible and reviewable.

Three practices would have helped with the issues I encountered.

First, architectural review should be available during story development, not only before or after it. Teams need a defined route for raising decisions that affect standards, component boundaries, lifecycle behaviour or other parts of the system.

Second, material architectural assumptions should be recorded in the stories they affect. This should not become another mandatory template section. It is useful when a story depends on something the specification has not stated, such as an initialization sequence, an upstream capability, a deployment condition or ownership of a cross-module interaction. Recording such assumptions gives reviewers something concrete to examine.

Third, architectural rules cited in stories should be traceable to a specification, an architectural decision record or another recorded decision. If no source exists, the rule should be treated as a proposal requiring review. This prevents a plausible generated interpretation from acquiring authority merely through repetition.

AI can support all three practices. It can classify potential architectural questions, compare assumptions across stories and validate references against the available documentation. The resulting workflow combines the tool’s ability to process a large volume of material with the contextual judgment and accountability of design authority.

A limitation in my own approach

During this work, I held both the architect and design-authority roles. I had written most of the specifications, maintained the standards and decision records, and followed the platform from its earlier stages. I therefore had the system-wide view represented in the specifications, the continuity behind earlier decisions and the authority to revisit them when the stories exposed a problem.

That combination helped me identify and resolve many of the issues described here. But working through such a large body of stories also exposed the other side of concentrating this responsibility in one person: the cognitive load can become significant. Holding the wider system context, the history behind earlier decisions, the relationships across specifications and the consequences of new decisions in mind while continuously reviewing and refining stories is difficult to sustain.

There is also an organizational dependency. A platform should not depend on one person remembering what every decision meant and why it was made. If architectural coherence resides mainly in one person’s memory, the organization has created a dependency rather than a sustainable design function.

The responsibility can be shared, but it should not be ambiguous. A more sustainable approach would distribute architectural knowledge while making clear who holds the relevant context, who can change an architectural decision and where the reason for that change will be recorded. The objective is not to centralize every choice, but to prevent system-wide decisions from being made accidentally within isolated stories.

AI can make the underlying architectural material easier to search and review, but it does not resolve the cognitive load, responsibility or accountability that comes with design authority.

Conclusion

Developing nearly 190 stories did not teach me that specifications leave implementation decisions open, or that detailed engineering work can cause architectural decisions to evolve. Those are familiar parts of software architecture.

What the experience made much more visible was the design-authority function operating in that space, and how much that function depends on capabilities that can easily be taken for granted.

The incidents described here required different forms of architectural judgment. Some required a view across components, some required knowledge of the system lifecycle, some depended on the history behind an earlier standard, and others required deciding whether an AI-generated finding represented a genuine architectural issue at all. The common factor was the need for someone with enough context to understand the consequence and enough authority to act on it.

AI was valuable throughout this process. It helped create the stories, review them, identify gaps and suggest alternatives. It can extend both the depth of exploration available to developers and the reach of architectural review. But increasing the speed and scale of those activities does not by itself provide the system-level context or accountability needed to govern the decisions that emerge from them.

This is why I believe design authority deserves more explicit attention in AI-assisted ways of working. The function may sit with an architect, a senior engineer, a technical lead or a small group. What matters is that organizations understand the capabilities it requires, develop those capabilities deliberately, and ensure that the function is present where the what meets the how.

My First Journey Outside India

My first trip outside India was in the winter of 1998. I was travelling to America, and Frankfurt was my first stop. While waiting at the airport, I decided to have some coffee and asked the lady at the counter for filter coffee. The lady did not understand what filter coffee was, and I did not understand what espresso was. The result of this miscommunication was that she handed me a single shot of espresso.

For me, drinking coffee had always meant one full tumbler. But here I was, looking at a very small cup containing an even smaller quantity of dark black liquid, trying to understand whether this was really what I had asked for. I took one sip, recoiled immediately and went back to ask her for some milk. She looked at me as if I had just insulted the coffee personally. That was my first cultural lesson, and I had not even reached America.

My port of entry was Chicago. After landing, I went through immigration and customs, collected my luggage and then walked out of the gate without realising that I had to check in my luggage again for the onward flight to Denver. By the time I understood what I had done, it was too late. I now had to take all my luggage on the airport train to the domestic terminal, negotiating several escalators along the way. Each escalator could take only one piece of my luggage at a time, so I kept going up and down, moving the bags one by one. There were lifts, of course, but I did not know about them and did not even think of looking for one. When I think about it now, I can only laugh at what a dumbass I was, struggling with five bags on escalators while a much easier option was sitting somewhere nearby.

This was my first time in America, and I was already overwhelmed. During that train journey, I saw several African American men who, in my frightened imagination, appeared to be seven feet tall. All the mugging stories I had heard before leaving India suddenly started running through my mind. They had done absolutely nothing, of course, and probably had not even noticed me. But I was in a completely unfamiliar country, carrying half my possessions with me, and feeling like a minion standing among giants.

To make matters worse, I had stepped outside the airport wearing only a thin sweater. It was November in Chicago, and I remember being told that the temperature was somewhere around minus 25 degrees Fahrenheit. I had come from a place where even 20 degrees Celsius felt very cold, so I was completely unprepared for what Chicago had in store for me.

Somehow, I managed the luggage, found the terminal, checked everything in again and finally boarded my flight to Denver. On board, the flight attendant gave me a packet of pretzels. I had never seen pretzels before, so the first thing I asked her was whether they were vegetarian. Pretzels—vegetarian? What sort of question was that? She must have gone back to the other crew members and had a hearty laugh about it.

When I tasted them, I did not like them one bit. I came from a land of spicy food, and here I was being given something that seemed unbelievably bland. I found myself looking around for ketchup so that I could somehow make the pretzels more interesting. This was well before the pancake incident, so clearly my instinct to solve unfamiliar American food with ketchup had started quite early.

A City I Had Never Heard Of

Denver was the first American city in which I lived. While growing up in India, I had heard plenty about California and New York through Hollywood movies. But Denver? I had never even heard of the place. I had no idea that this unknown city was about to become such a large part of my life.

From the moment I arrived, I was mesmerised by America. The roads were huge, the cars were huge, and even the parking lots seemed enormous. Stores such as Best Buy and Walmart fascinated me. I could spend hours walking around inside them, looking at things I had never seen before and occasionally buying things I probably did not need.

The weather in Denver was beautiful, and the sky seemed unusually large and blue. The mountains were always there somewhere in the distance, forming a backdrop to everyday life. Our office was on the eleventh floor of a building in downtown Denver, and from there we could see the Rockies. I would sometimes stand near the window and simply look at them over a cup of coffee. For a young man who had recently arrived from India and who had not seen snow capped mountains, it was a magical view.

We were a bunch of youngsters from the same company, all in our twenties. We had come there to work, but we were also eager to see and experience everything around us. Most things were new to us, and that probably made even ordinary experiences memorable. We were curious about America, and America kept giving us new things to be curious about.

Learning America, One Misunderstanding at a Time

During my first week in America, I bought an AIWA music system and was extremely proud of it. Soon afterwards, our apartment was burgled and the music system was stolen. When the police arrived, their cautious questioning somehow made me feel as though we were also being treated as possible suspects. We had just lost our belongings, and I was beginning to wonder whether I had to prove that I had not stolen my own music system. But none of this reduced my enthusiasm for America. I simply went out and bought another AIWA music system.

Our American manager, Steve Anderson, made a special effort to help us settle in. One day, he took us to Denny’s for breakfast and suggested that we order pancakes. None of us knew what pancakes were. When they arrived, we examined them carefully and, after some discussion, asked for ketchup.

The expression on Steve’s face was unforgettable. He looked at us as though we had landed from another planet. He simply could not comprehend how an entire table of grown adults had reached America without knowing what a pancake was. We, on the other hand, could not understand what was so shocking. The pancakes were sweet, while our taste buds were looking for something spicy. What else could we use other than ketchup or Tabasco sauce? To us, the request seemed perfectly reasonable.

Eating outside was always an investigation in those days, especially for vegetarians. We would ask whether a dish contained beef-based sauce, and then whether it had been fried in the same oil as chicken. Sometimes the person serving us became more confused than us! We only wanted to make sure that the innocent-looking brown sauce did not have some beef stock inside it.

Learning to drive was another adventure. None of us knew how to drive before we arrived in Denver; we all learnt there from scratch. And we did not learn under easy conditions either. We learnt during winter, on snowy and icy roads, while also becoming familiar with American cars and traffic rules. When I look back now, I genuinely wonder where we found the courage. Perhaps that is how we were in our twenties—the decision came first, and the reasoning followed much later. We had decided that we needed to drive, so we simply went ahead and learnt.

Some of my colleagues once jumped a traffic light. A police vehicle came behind them with its lights flashing, but they did not realise that this meant they had to pull over. They continued driving for miles, and the police continued following them. Our friends eventually drove all the way back to our apartment complex, unknowingly leading the police directly home. By the time they stopped, four or five police vehicles had surrounded them.

Those of us watching from the apartment could not understand what major crime they had committed during their short trip outside. The police, in turn, probably could not understand why anyone would lead an entire police convoy to their own home. The misunderstanding was eventually sorted out, but for a short while our apartment complex had more police vehicles than residents.

Once the Roads Opened Up

Once we got our driving licences, the roads opened up for us. Our first major road trip was to South Dakota to see Mount Rushmore. After that, we drove from Denver to Las Vegas and the Grand Canyon. We went to Yellowstone National Park by road and took many shorter trips in and around Colorado.

The mountains became a regular part of our lives. We drove several times on the hilly roads between Denver and Aspen, saw Aspen in its fall colours, travelled through Independence Pass and drove along Trail Ridge Road in Rocky Mountain National Park. We went to Durango and explored many places whose names I had not known a few months earlier. Some roads were covered with snow, some were surrounded by golden trees, and on many of them we would stop simply because the view was too beautiful to drive past.

There were also many beautiful bicycle trails. I became so fascinated with cycling that I bought a bicycle and fitted a cycle rack to my car. Today, this may sound quite ordinary, but in my circle at that time, only a few people had a cycle rack on their car. I would sometimes cycle to the office, which took roughly forty minutes. Part of the trail ran parallel to a stream. Can you imagine cycling to work beside a stream? It felt magical.

A friend from those days now works in the same building as me. Just last week, he told me, “Anand, we were all thinking that you would leave our company then and become a full American because of the way you lived your life.” Perhaps they had some reason to think that. I started dressing like Americans, would eat like them, travel around like them! I was living life king size!

The Life We Made There

Downtown Denver had its own charm, and we spent a lot of time around the 16th Street Mall. Christmas felt exactly as it did in many Hollywood movies—quite romantic and beautiful. There were lights everywhere, people walking around in winter clothes and that special festive feeling in the air. During Christmas, there was also the eggnog latte from Starbucks, which somehow became part of that whole American Christmas experience for me. We watched the New Year fireworks and enjoyed all these moments without thinking that we were creating memories we would still be discussing decades later.

Our apartment life produced its own set of memories. One of our friends came to stay with us and brought along his 55-inch television. For us, a television of that size was something we had never seen before, and having it at home transformed the apartment into a theatre. Naturally, we watched movies at a volume suitable for a theatre as well.

The apartment had wooden floors, and sound travelled easily to the people living downstairs. Along with the television, we also had our pressure cooker, which regularly made its presence known. One day, the downstairs neighbour complained that we were “running a train every night.”

For some time, we honestly could not understand what he meant. How could anyone run a train inside an apartment? Where will we hide it? How did we take it to the top floor? What are these guys thinking about?

Eventually, we realised that the loud movies, the sound travelling through the wooden floor and the pressure cooker had combined to create what sounded like a railway operation downstairs. Without realising it, we had apparently become engine drivers and were comfortably running a train inside our apartment every night.

Keep a Good Thought

Years later, after I got married, I travelled from Tampa to Denver with my wife because I wanted to introduce her to Steve. He and his family had welcomed us so warmly during our early days in America that they had made me feel completely at home. That was why it mattered to me that he meet my wife. During those years, I had often told him that he should visit India and that I would host him for as many days as he wanted.

Thinking of Steve and Denver always brings a wide smile to my face. These memories also bring back the same curious small-town boy attitude I had then—fascinated by everything and eager to experience all of it. I was carefree, I was fearless, and I was so, so, so happy. That was probably the main reason those years remain so close to my heart.

I do not remember every conversation from those days, every road we travelled or every place where we stopped. But I remember how those years felt. And whenever I think about them, I can still hear something Steve used to tell me:

“Anand, keep a good thought.”

All these years later, I still do.

Buying an electric car felt like a path-breaking decision.

I was going to reduce my dependence on petrol, lower my running costs, and take one small but meaningful step towards the future. While everyone else was still debating whether electric vehicles were ready for India, I was prepared to move ahead.

Not recklessly, of course.

I was keeping my petrol car.

Many people had advised me not to buy an EV yet. The technology was still maturing, they said. Charging infrastructure was not widespread enough. Battery life was uncertain. Long-distance travel required planning. Resale value was another mystery waiting patiently in the future.

These were all reasonable concerns. But my daily requirement was much simpler.

I travel to the office three or four days a week, and each round trip is approximately 40 kilometres. That is between 120 and 160 kilometres of commuting every week, much of it spent watching the petrol gauge move steadily in the wrong direction.

For this kind of predictable city travel, an EV made complete sense. I could charge it at home, use it for my office commute, and significantly reduce my running expenses.

The petrol car would remain available for longer journeys until I developed more confidence—or until India installed a charging station every few kilometres, whichever happened first.

Among the EVs I considered, I eventually narrowed my choice down to the Punch EV largely because of its promised range. My regular commute was only about 40 kilometres, but a stated real-world range of more than 330 kilometres gave me a comfortable buffer.

It made the decision feel practical rather than adventurous.

The decision was therefore bold, progressive, environmentally responsible and financially sensible.

Then I charged the car.

After the initial charge had drained, I gave it its first full charge.

The dashboard showed 267 kilometres.

I stared at the number.

The stated real-world range was above 330 kilometres. That range was one of the reasons I had chosen this car in the first place.

I knew enough about vehicle advertisements not to expect the complete figure. Mileage claims have always belonged to a slightly more optimistic universe than the one in which we drive.

But 267?

For the first time since buying the car, I seriously wondered whether I had made the right decision.

I looked at the dashboard again. In Vadivelu’s voice, my mind asked:

“என்னைய வச்சு காமெடி கீமெடி பண்ணலையே?”

Where had the remaining kilometres gone?

Had they disappeared during delivery? Was the battery defective? Had I accidentally bought the Empowered Minus model? Should I call the dealer and ask for my missing range?

Until that moment, I had not fully understood that the number displayed on the dashboard was merely an estimate.

Coming from a petrol car, my mental model was straightforward. You fill the tank. The gauge shows full. You drive. The needle comes down. There is a reassuringly mechanical relationship between fuel consumed and distance travelled.

The EV dashboard, I would soon learn, was not reporting the future.

It was guessing.

I considered calling someone immediately, but decided to do what engineers do when a system behaves strangely and there is not yet enough data to blame anyone.

I observed.

Over the next few days, something even stranger happened. The displayed range increased from 267 kilometres to around 280.

That was encouraging.

Then it remained around 280 even after I had driven nearly 80 kilometres.

That was not encouraging. That was confusing.

My brain tried to derive a formula from the available evidence:

Initial range: 267 km
Distance driven: nearly 80 km
Current displayed range: approximately 280 km

According to the dashboard, I had driven 80 kilometres without losing any range. In fact, the car appeared more confident about its future than when I had started.

I was still treating the range as though it were making a commitment. The car was treating it more like a Vadivelu comedy:

“வரும்… ஆனா வராது.”

The range would be there—but also not be there. It would fall, rise, remain unchanged, and occasionally become more optimistic after I had driven the car.

I had bought an electric vehicle. Apparently, the dashboard came with its own sense of humour.

This was when I began learning about regenerative braking.

The term itself was not entirely new to me. I had heard about energy recovery systems through Formula 1, where energy generated during braking is captured and reused. It sounded impressive when explained during a race, although I had never imagined it would become relevant to my office commute.

Now I could actually see it working in my own car.

Every time I eased off the accelerator or applied the brakes, the car was not merely slowing down. It was recovering some energy and feeding it back into the battery.

I had one piece of Formula 1 technology in my car.

Admittedly, I was using it to crawl through office traffic rather than challenge Lewis Hamilton, but that small connection made me strangely happy.

It felt like a cashback scheme for driving: spend energy while accelerating, and receive a small portion of it back when you slow down.

Regeneration alone probably did not explain the entire mystery. The car was also learning from my recent driving efficiency and revising its estimate. The original 267 kilometres may have been a cautious guess. After observing how I drove, it had become more optimistic.

So while I was trying to subtract every kilometre travelled from the number on the dashboard, the car was performing a completely different calculation—consuming energy, recovering some of it, studying my driving, and repeatedly changing its mind about the future.

The battery percentage was a measurement.

The range was an opinion—an opinion that could improve after getting to know me.

I decided to stop arguing with the opinion and collect my own evidence. On the next charging cycle, I reset the trip meter and allowed the battery to drain much further.

From a 92 percent charge, the car covered more than 280 kilometres.

That was a much more satisfying number—not because it matched the stated range exactly, but because I had measured it myself.

The battery was fine. The car was fine. I could comfortably manage my regular commute.

Confidence had arrived.

Then, one day, the battery dropped to 20 percent.

I had approximately 45 kilometres to travel that day. Based on everything I had measured, 20 percent should have been enough.

But “should have been enough” is not the same as “I am completely relaxed.”

I asked ChatGPT.

It considered the battery percentage, my previous range, and the distance I needed to travel. It performed the calculations and assured me that the car would not stop halfway.

ChatGPT was calm.

I was collecting emergency phone numbers.

My concern was no longer about range in the abstract. My imagination had moved to a much more specific scenario:

What happens if the car stops in the middle of traffic?

Would it give me some final warning? Would it slow down gracefully? Would everything simply switch off? How would I move it? Whom would I call? Would a breakdown vehicle arrive with a giant power bank?

I feverishly saved the service number, roadside-assistance number, and every other contact that might become useful. Anyone looking at me would have assumed I was preparing to cross a desert.

I was going to the office.

But beneath the anxiety, another instinct had started operating—the urge to test the boundary.

Calculations could reassure me, but I wanted real evidence. I needed to know how the car behaved when the displayed percentage became uncomfortable. Otherwise, every future journey would become another mathematical exercise followed by an emotional crisis.

So I drove.

The car completed the entire journey without drama. No warning lights. No roadside-assistance calls. No traffic jam caused by a newly converted EV enthusiast.

When I returned home, the battery had dropped by only about 10 percent.

ChatGPT’s prediction had been almost exactly right.

More importantly, I now understood my car a little better. Twenty percent was no longer an abstract and frightening number. I had tested it against my actual commute, driving style, traffic and air-conditioning use.

After three full charging cycles, I still feel a small wave of anxiety whenever the dashboard shows a low figure. But it is becoming manageable.

I am also learning that owning an EV requires a different relationship with numbers.

In a petrol car, the fuel gauge tells you approximately how much petrol remains. In an EV, the battery percentage tells you how much charge remains—but the range display tries to predict what you will do with it.

It considers speed, traffic, terrain, air-conditioning, driving style, recent consumption and the energy recovered through regeneration.

It may be sophisticated, but it is still a prediction.

The number is not saying:

“You can definitely travel this far.”

It is saying:

“Based on the limited time we have spent together, this is what I currently think you are capable of.”

Some days it trusts me with 280 kilometres. Some days it is less optimistic.

Perhaps my car also has owner anxiety.

Every time I switch it on and stare suspiciously at the estimated range, it seems to respond with that familiar line from Sivaji:

“வாங்க… பழகலாம்.”

Fair enough.

The car and I are still getting to know each other.

There are some places we remember because of a particular occasion. A birthday, a family function, a college reunion, or perhaps one memorable meal. And then there are places that somehow become part of everyday life itself, so deeply woven into our routines that we stop thinking of them as destinations.

For many of us who grew up in Chennai, Saravana Bhavan was one such place.

We called it SB. We went there when we were happy, when we were sad, when we wanted to celebrate, when we wanted to meet friends, when relatives came home, when we simply had nothing to do and were bored, and sometimes just because someone said, “Shall we go to SB?” That was enough. We never really needed a reason.

My own memories of Saravana Bhavan probably go back to when I was in ninth standard. We were living in KK Nagar then, and the Saravana Bhavan there became one of our favourite haunts. I do not remember my first visit, but I remember the food vividly.

My favourite was always parotta with kurma. And then there were their famous 14 Idlis — those tiny idlis soaked in sambar that Saravana Bhavan made so memorable for us. Even today, I can almost taste that kurma and sambar when I think about them. If I ordered a ghee roast, the real hero was again the sambar. There are some flavours that remain in memory not merely because they tasted good, but because they get permanently associated with an entire period of life. Saravana Bhavan’s kurma, sambar and those 14 Idlis belong to that category for me.

During our school days, eating out was still something of an occasion, and money mattered. That was probably why the unlimited meals at Saravana Bhavan had such an irresistible appeal to a bunch of growing boys with very healthy appetites and very limited budgets. If my memory serves me right, a meal cost somewhere around thirty or forty rupees then, and the word “unlimited” opened up several creative possibilities in our teenage minds.

Three or four of us would sometimes take turns eating from the same meal. One person would eat for a while, and then someone else would continue. Looking back, I am not particularly proud of our contribution to restaurant economics, and I occasionally wonder whether people like us were responsible for the rule that later appeared saying meals could not be shared.

Their special meals were an event in themselves. They would begin with soup, followed by a variety of vegetables, a chapathi or poori, kurma or potato masala, and then rice with all the usual accompaniments. For a good part of the meal, the vegetables, sambar and other items would keep coming. Just when your body had clearly communicated that no further food was required, dessert would arrive, usually followed by sweet paan.

Once you finished one of those meals, productivity for the rest of the day was more or less over. The only sensible thing left to do was sleep.

One particular dinner remains permanently etched in my memory. My parents were out of town, and my cousin, my brother and I decided to go to Saravana Bhavan for dinner. We were young, very hungry, and blessed with the extraordinary confidence of that age, when you believe that your stomach has no upper limit.

We started ordering and simply did not stop. One dish led to another, then something else on the menu looked tempting, and naturally we ordered that too. There was no concept of portion control, no calorie counting, and certainly no inner voice telling us that perhaps we had eaten enough.

And after all that, there was still one thing left to order: falooda.

The falooda that Saravana Bhavan served in those years deserves a place in my memory all by itself. I have had falooda in many places since then, but somehow nothing has matched what I remember from those days. It was rich, cold, sweet, completely unnecessary after the amount of food we had already eaten, and absolutely irresistible.

We somehow finished dinner and came out. Our house was probably half a kilometre away. Under normal circumstances, that would have been an easy walk. That night, we simply could not do it. We hired an auto to get home.

That probably tells you everything about the meal.

As the years passed, Saravana Bhavan also seemed to grow along with us. The number of branches increased across Chennai, and for us, more branches only meant more opportunities. KK Nagar, Ashok Nagar, T Nagar and several others became familiar names. By the time we started working, SB had become a perfectly respectable place for office treats as well.

Then came the AC halls, which somehow felt very sophisticated at that stage of life. You could now take colleagues out, sit in air-conditioning, and still order the same dosa, meals, parotta and coffee that had been part of your growing-up years. Our lives were changing, but Saravana Bhavan remained reassuringly familiar.

Years later, 14 Idlis would also make an appearance at a rather important moment in my life.

My first outing with my wife, before we got married, was to Saravana Bhavan. And what did I order? Fourteen Idlis.

Apparently, this did not create quite the impression I imagined.

She later went home and asked her mother something along the lines of, “This guy takes me to Saravana Bhavan and eats mini idlis! Am I getting married to some old-fashioned amanji?”

The funny part is that the choice itself had hardly involved any thinking. First outing or otherwise, the instinct was simply: go to SB. And once there, 14 Idlis seemed as natural a choice as anything else.

Years later, of course, she herself became a big fan of SB. So I would like to believe that history eventually proved me right.

Over time, SB stopped being just my favourite place and became the family’s default restaurant. That meant something very specific. If I said, “I am going to SB,” nobody needed a formal invitation. My parents might come, my in-laws might join, my wife’s aunt’s family might get ready, and sometimes people would simply jump into the car after hearing where we were going.

There was no debate about cuisine, no shortlist of restaurants, no discussion about ambience. The announcement itself was enough: “I am going to SB.”

Everybody in the family developed their own favourites too. My dad’s favourite combination was tomato soup followed by rava dosa. My elder daughter’s favourite was always masala papad, while my younger daughter chose a dish very close to my own heart — 14 Idlis. My father-in-law became a badam milk loyalist after I introduced him to it, and later I introduced falooda to him and to my daughters as well. Slowly, another generation acquired its own relationship with the place.

That, in many ways, was the charm of Saravana Bhavan. Everyone had their dish. You did not always go there wondering what to eat. Often, you went already knowing exactly what you would order and, more importantly, exactly how you hoped it would taste.

One memory from after my marriage still makes me smile. My wife’s grandmother had been admitted to a hospital in Ashok Nagar, and as luck would have it, there was a Saravana Bhavan right outside the hospital. Naturally, every visit to the hospital also created an opportunity to step into SB.

What else could I possibly do?

It was during those visits that I introduced my wife and my father-in-law to their badam milk. My father-in-law loved it, and from then on, whenever I took him to Saravana Bhavan, badam milk became almost automatic. Later came falooda, which he and my daughters also came to enjoy.

Food memories often travel through families in exactly this way. You discover something when you are young, years later you introduce it to someone else, and then one day you realise they have developed their own ritual around the same place.

Friends were no different. Today, choosing a place to meet can become a project by itself. One person wants one cuisine, someone else wants another, somebody is looking for a quiet place, and another person is searching for the newest restaurant in town.

Our meetings were much simpler.

The question was rarely “Where shall we go?” It was more likely to be “KK Nagar SB or Ashok Nagar SB?” And most of the time, KK Nagar won.

So many lunches and casual meetups with friends happened there over the years. We were never looking for a fancy venue. We just wanted a place where we could sit, talk, eat and spend time together, and Saravana Bhavan was always the obvious choice.

Even today, when school or college friends meet, SB somehow gets woven into the conversation at least once. Nobody deliberately brings it up. It just appears, almost like saying, “I woke up this morning and had coffee.” That was how routine it had become in our lives. SB did not need a special mention because, in some strange way, it was always already part of the story.

When I returned to Chennai after living outside the city for many years, SB returned to my life yet again. Our weekend haunt became the KK Nagar branch. There is something deeply comforting about returning to a city and finding an old habit waiting for you.

Years may have passed. Jobs may have changed. You may have got married, had children, accumulated responsibilities and lived in different places. And then one weekend, you sit down in a familiar restaurant and order something you have eaten for years. For a few minutes, all those intervening years seem to disappear.

Our attachment to SB was so strong that it travelled with us. When we were abroad and planning a trip to California, we made it a point to eat at Saravana Bhavan there. The same happened in Singapore, and even in Canada. If SB was around, food became one less thing to think about. There was no hesitation, no need to study menus or search for reviews. We just ordered from SB.

There was something deeply comforting about seeing that familiar name in another country. In a place where almost everything around you was different, Saravana Bhavan immediately felt known. You knew the food, you knew the menu, and more importantly, you trusted what would arrive on the table. For a little while, it felt as though a small piece of Chennai had travelled with you.

Eventually, the Saravana Bhavan restaurants that had been such a big part of our Chennai life shut down. The city moved on. New restaurants came up, food delivery became normal, eating out became far more common, and our own lives changed in ways we could never have imagined when we first walked into the KK Nagar branch as schoolboys.

But even today, when I pass some of those old properties, the memories come back.

I do not remember every meal or every conversation, and I certainly do not remember every bill. But I remember the feeling. I remember school friends, family outings, office treats, long lunches, tomato soup and rava dosa, masala papad, badam milk, parotta and kurma, 14 Idlis, that unforgettable sambar, and of course the falooda that once made three young men incapable of walking half a kilometre home.

Even now, when I travel between Chennai and Bangalore by road, I sometimes stop at the Saravana Bhavan near Kanchipuram for breakfast or dinner. Perhaps, without really thinking about it, I am still keeping that connection alive.

Because for many of us who grew up in Chennai, Saravana Bhavan was a feeling, not just a restaurant. It was familiarity, comfort, friendship, family and routine, all rolled into one. It was there while we were growing up. It saw us as schoolboys, friends, young employees, husbands, fathers and families.

We never needed a reason to go.

Saravana Bhavan itself was reason enough.

Bombay was probably my first real turning point.

By the time I reached there, I had already understood that technical ability alone was not enough. I had made mistakes, I had lost an opportunity, and I knew I had to rebuild myself in more ways than one.

So I worked like crazy.

There was very little distinction between day and night. Work and learning simply became part of the same cycle. At the previous company, one of the reasons given for rejecting me was that I was not good enough at socket programming. So in Bombay, I started writing multithreaded socket programming so many times that I sometimes feel I could probably write it even today with my eyes closed.

It became personal. I needed to prove to myself that if I did not know something, I could learn it.

Bombay also gave me something equally important: exposure. I met smart people, made friends, and began understanding how others communicated, dressed, behaved and carried themselves. My English improved steadily. The foundation laid by my English teacher, along with years of watching British programmes and reading, started showing results.

I became independent too. I survived on very little money but still managed to have fun — bhel puri, pani puri in Juhu, South Indian food in Matunga, movies watched repeatedly, and a five-rupee Mysore masala dosa near my apartment. I was lucky enough to live almost opposite my office, so life was simple.

Somewhere in that period, I also started paying attention to personal grooming. Good clothes, clean shoes, perfume, toiletries and neatly maintained personal belongings began to matter to me. I did not want to go to office in a crumpled shirt, and I did not like leaving my bed unmade.

That influence probably came from more than one place. One of my aunts dressed impeccably well and carried herself with great style. My father too was always extremely neat and well-dressed when he went to work. Without realising it, I was collecting habits from people around me and slowly becoming a more polished version of myself.

Then Denver happened.

If Bombay changed me, Denver refined me.

Very early in my career, I began getting noticed in my division. People started saying things like, “Oh, that Anand? He can crack anything.” I became the firefighter. If a project had a difficult problem, I would get pulled in. If the solution was unclear, complicated or high-risk, I wanted to be there.

I had only two or three years of experience in the industry, but I was already handling situations that were far more complex than anything I had imagined doing so early. It did not happen easily. It was toil, toil and more toil, but it was also enormous fun because I had a wonderful group of friends around me. Many of us are still in touch, still meet, and still talk about those days.

Denver also gave me one of the most important mentors of my career. My manager there took me under his wing.

I was driven, ambitious and technically aggressive. I would raise my hand for everything. I wanted to solve every problem, and not surprisingly, that attitude sometimes rubbed people the wrong way.

My manager understood me very early. He did not try to reduce my drive. Instead, he taught me how to channel it — how to work with people, how to conduct myself, how to disagree, and how to get things done without making every interaction a battle.

His influence on me was enormous. By the time I left Denver, I was a very different professional from the person who had arrived there.

I had also discovered a kind of freedom I had never really experienced before. I cycled to work, went on long drives, drove into the mountains, and spent time around snow, lakes, peaks and roads that are still etched in my memory. Years later, when I visited Denver again, the place still felt magical.

From there, life moved into a completely different phase.

Marriage happened in 2001, and I very quickly discovered that whatever I had learnt professionally was not automatically useful at home. Family life had a completely different syllabus. There was no training manual and no mentor sitting beside me explaining what to do next.

My wife became one of the biggest influences in shaping and polishing me during this phase of life. In many ways, she was one of the major reasons the raw person I was slowly became the person I am today. She brought a different way of looking at people and situations, and over the years she made me more balanced, more patient, more socially aware and much more conscious of how I came across to others.

She also taught me something I had taken a long time to learn: being right was not always the most important thing in a conversation.

Then came my daughters, and they refined me further. They made me more flexible, more approachable and taught me when to speak, when to listen and, sometimes, when to simply leave things alone.

I had spent years learning how to become a better professional. My wife and daughters quietly taught me how to become a better person.

My career continued to grow through different organisations, countries, cultures, personalities and increasingly demanding professional situations. Every phase took away another rough edge. I learnt to communicate better, listen better, handle difficult conversations with more maturity, and understand that getting something done through people required a very different skill from simply knowing the answer.

By then, the small-town boy had travelled quite a distance.

Life, of course, did not become perfect. There were difficult personal and health-related years that changed the way we looked at life as a family. Those years slowed me down, made me think more, and perhaps planted the seeds for much of the reflective writing I do today.

And through all these stages, there has been another constant in my life — my faith.

My belief in Kanchi Mahaperiyava and Shirdi Baba has grown with me over the years. There were periods when life was moving beautifully and periods when I did not know what was coming next. There were doors that opened unexpectedly, people who appeared at exactly the right time, difficult phases that somehow passed, and situations where I could only look back later and wonder how things eventually fell into place.

I have always felt their presence through these moments.

I do not claim to understand how everything works, nor do I believe that faith means life will always go the way we want. But I do believe that I have been guided, protected and nudged in the right direction through many stages of my journey.

When I look back today, I cannot separate that faith from the person I became. Without the blessings of Kanchi Mahaperiyava and Shirdi Baba, I genuinely do not think I would be sitting here today looking back at this journey with this sense of gratitude.

Somewhere along the way, another idea stayed with me through a movie I loved — Abhiyum Naanum. It is a story about a father growing along with his daughter, learning to let go, learning to accept, and learning that life does not always unfold exactly as expected.

Through all of that, one simple thought stayed with me: life is beautiful.

I relate to that more and more as I grow older. My life has had confusion, failures, mistakes, difficult years and plenty of situations that did not unfold the way I expected them to. But when I look at the whole picture rather than individual episodes, I still come back to the same conclusion.

Life has been beautiful, not because everything went right, but because somehow I kept moving.

Whenever something did not work, I usually found another route. Maybe that is one quality that has stayed with me throughout my life: flow like water. If one route closes, look for another. Do not stay stuck.

When I look at myself today, I can see how much has changed. I can travel anywhere, walk into a room full of strangers and speak, handle difficult conversations, work with people from different cultures, and deal with situations that the younger version of me would probably have run away from.

I am probably what my younger self would have called a “city person,” but I do not really feel that way inside.

Somewhere in me, I am still that small-town boy — the boy who could spend an entire day playing cricket, make a cricket ball out of paper and rubber bands, spend his bus fare on kulfi and walk home claiming he had special class, drink borewell water, run through fields and eat whatever he found growing there, last three days in karate, injure himself dancing, and have no idea what a board exam was until it almost arrived.

He was curious about everything, personally naïve, emotionally intense, increasingly independent and constantly learning after making mistakes.

I did not become who I am through one dramatic transformation. It happened through transfers, cricket matches, comic books, blank exam papers, good teachers, job rejections, mentors, cities, friendships, my parents, my wife, my children and a lot of trial and error.

The funny thing is that I spent a large part of my life trying to become less like that raw small-town boy — more polished, more confident, more articulate and more sophisticated.

And now, after becoming all of that, there are days when I wish I could borrow a little bit of him again.

His lightness, his curiosity, his ability to spend an entire day doing something simply because it was fun, and his freedom to run outside with a bat and ball without worrying about what tomorrow looked like.

I know I cannot become that boy again, but I hope I never completely lose him either.

After all, everything I became was built on top of him.

And after all the twists, mistakes, people, places and lessons that brought me here, I can say this with complete conviction today:

Life is beautiful.

A few days ago, my wife told me, “You should write about how you were this small-town boy and how you became who you are now.”

I laughed, not because the idea was bad, but because I immediately knew I had enough material to write a book.

I was born in Kanchipuram, in a very traditional family. My LKG was in Mylapore, Chennai, though I remember very little from that period. One memory is of me and a friend being punished for talking too much in class. My mother was waiting outside with my lunch and became anxious because I had not come out. When she finally came looking for me, she found me kneeling down next to another boy. She was shocked because, at home, I was apparently this quiet child who hardly spoke. Maybe that was the first time she discovered that I had two versions. That split personality has survived very well into adulthood. I am a Gemini, after all. I have to blame something.

There was also a classmate named Sridevi. Apparently, one of my favourite pastimes was pulling the ribbon or rubber band from her hair. My mother still remembers it. What is worse is that even today I sometimes do exactly the same thing to my daughters. Some habits have remarkable longevity.

Then my father’s job took us to Trichy. My dad worked in a bank, and in our family we sometimes joked that the bank was probably his first wife. I joined another kindergarten there, and what I remember most about that school is that they occasionally screened movies. Those were the days when I suddenly became very interested in attending school.

Our headmaster also used to listen to cricket commentary on the radio. A bunch of us, probably UKG or first-standard kids, would stand around him and listen with great seriousness. I had absolutely no idea what cricket was. I probably did not even properly understand what a radio was. But everyone was listening, so I listened. When I think about it now, that curiosity was there very early. I did not need to understand something before getting interested in it; I just wanted to know what was happening.

They soon moved me to another school in Trichy, this one run by the Periyar Maniammai Trust. So at a very young age, I was being taught why many Hindu practices were meaningless, misleading and should be questioned. Nothing much went into my head. The school had gardens, fields and borewells, and they were far more interesting to me than whatever was being taught in class. We would pump water from the borewells, drink until our stomachs were full, get into the fields, eat gooseberries and whatever else we could find, and occasionally get chased by gardeners. That was the reality of my education at that stage.

I was also far more interested in comic books than textbooks. I used to pester my mother every week to buy me comics, and Irumbu Kai Maayavi was one of my favourites. On television, Giant Robot had me completely hooked. Many years later, I became a huge Iron Man fan. Looking back now, I think I know where all of that started.

Before I could settle down there, my dad got transferred again. By the time I finished school, I had studied in eight different schools between LKG and 12th standard. That may not be a national record, but it is probably a family record.

The next move was to Chengalpattu, and that was probably the happiest part of my childhood. Until then, I had been the only child and had enjoyed the full attention of my parents. Then competition arrived in the form of my younger brother. Surprisingly, his arrival gave me freedom because my parents were suddenly busy with him, and I used that freedom very efficiently.

I was only around fifth standard, but I would roam around Chengalpattu with a bat and ball in hand, looking for somewhere to play. If there was a ground, I wanted to be on it. By then, cricket had completely entered my head. Gavaskar, Vengsarkar, Srikkanth and Kirmani were names that mattered greatly to me. Studies did not. There simply was no time for them.

My mama and I could play cricket with almost anything that could be made to behave vaguely like a ball — paper rolled up and tied with rubber bands, erasers, tennis balls, rubber balls, cork balls, anything. Yes, erasers too. Naturally, we were also responsible for a reasonable amount of property damage. Window glasses, shop windows, pictures at home, porcelain jars — if it could break, there was a fair chance that cricket would eventually find it.

Around 1983, my dad bought a Solidaire television. I vaguely remember watching cricket during that period, and whatever I watched on TV had to be immediately recreated on the road outside. Injuries were routine. I would scrape myself against iron fences, fall down, come home bleeding, apply Ponds powder on the wound, sit quietly for a while, and then go back out and play. I did not know anything about antiseptic lotions or tetanus injections. My parents would probably have taken me to a doctor if they had known half the things I was doing outside. For me, Ponds powder was enough and play was compulsory.

There was a karate class opposite our house. I was fascinated by the uniform, the movements and the whole atmosphere, and I pestered my mother until she finally agreed to enrol me. She was reluctant because she knew me well, and she was right. I lasted about three days.

Around the same period, I was constantly dancing at home. Kamal Haasan was a big influence, while I would style my hair like Rajinikanth and attempt Kamal-style performances. One afternoon, I was dancing to “Ennadi Meenakshi, Sonnadhu Ennachu,” jumped or flipped onto the bed and sprained my neck. I started crying, while my mother and my aunt started laughing. I became furious. Much later, I discovered that they had apparently been discussing when exactly I would injure myself. I proved them right. Very predictable.

By then, my younger brother had started crawling and walking, which created a new problem. Whenever I tried to play cricket in the front porch, he would crawl down the steps and sit right in the middle of the playing area. I would carry him back inside, and before we could restart, he would crawl back again. Eventually, because of him, I started going to the larger grounds around Chengalpattu. So I suppose I owe some part of my cricketing freedom to my brother.

Then came a strange period. Indira Gandhi was assassinated, the Sri Lankan conflict was in the news, and there was also a massive teachers’ strike in Tamil Nadu. My sixth standard more or less disappeared. I honestly do not remember attending school for more than a month or two. For me, this was fantastic news because more holidays meant more cricket. Around this time, one of my dad’s friends brought me a full cricket kit from Jalandhar, which could not have been timed better.

Then my dad was transferred again, this time to a small village where there were no proper schools. So I was sent to Kanchipuram to stay with my grandmother. Unfortunately for anyone interested in my education, my mama was also there, so the playing continued.

The school I joined there was hardly a school in the way I understand schools today. There would sometimes be only two classes in the whole day, teachers would be absent, and nobody seemed particularly worried. We played everything — cricket, football, gilli-danda, seven stones and kho-kho.

During lunch, we would sometimes get onto bullock carts, go to distant fields, get muddy, eat sugarcane, cucumber, raw mangoes and whatever else was available. Those were simple pleasures, and I still miss them.

Sometimes I would spend my bus fare on kulfi and then walk all the way home. My grandmother would ask why I was late, and I would confidently say, “Special class.” Poor soul believed me until one of my classmates who lived on the same street casually informed her that I had actually been playing in the school ground.

At no point during all this did studies occupy any serious part of my mind. Nobody seemed particularly worried about it either.

And then Chennai happened.

My parents decided to move to Chennai and put me into a proper school for eighth standard. We tried in several schools before finally landing in one in K.K. Nagar. There was an entrance test, and that test remains one of the great reality checks of my childhood.

I genuinely did not know what to write. The school I had attended in seventh standard had hardly taught me anything, so I gave back what was essentially a folded blank paper. Much to my surprise, after all the running around and that glorious blank-paper performance, I finally got admission into the school in K.K. Nagar.

That may have been the first proper jolt in my journey from small-town boy to city kid.

The next six months were terrible. One challenge was adjusting to Chennai. The bigger challenge was adjusting to something even more unfamiliar: full-time school. I had not really attended a proper full year of school since around fifth standard, so sitting in class continuously and actually paying attention was exhausting.

I hated going to school. Until then, life had meant fields, cricket grounds, streets and freedom. Now I was in an unfamiliar city, in a structured classroom, expected to know things that everyone else seemed to know already.

I somehow scraped through eighth and ninth standard. And, naturally, I found another cricket gang. We would go from sector to sector in K.K. Nagar looking for games, and at the smallest opportunity I would run out of the house.

Home, meanwhile, was never short of activity. There were relatives, visitors, family discussions, debates, arguments and one story or another unfolding almost every day. Looking back now, I sometimes think some of the television serials that came much later could easily have borrowed their scripts from our house. There was certainly no shortage of drama.

My parents had a lot to manage, my brother was still very young, and I was somewhere in the middle trying to make sense of school, cricket and growing up. So, without anyone consciously planning it that way, I started learning to manage quite a few things on my own.

Then tenth standard arrived.

I had absolutely no idea what a board exam meant. I did not understand how important it was or how the marks could affect what I could study later. I look back now and find that almost unbelievable.

This was also adolescence. Mine was a co-education school. There were boys and girls in class who were far more confident, socially comfortable and city-bred than I was. I had very poor English-speaking skills. I did not know how to start conversations, and I was shy enough to avoid people rather than talk to them. I was still very much a small-town boy trying to understand city life.

Then, about a month before my board exams, my mother found a mathematics tuition teacher, and that changed everything.

For the first time, someone made mathematics make sense to me. Around the same time, I also went to my English teacher for tuition. He was a wonderful teacher. His classes introduced me properly to English literature, and I remember being fascinated by his lessons on Arthur Conan Doyle. That influence stayed. During college, I would later go to the British Council Library and watch Sherlock Holmes episodes regularly. Even today, Sherlock Holmes remains one of my favourite fictional characters.

Slowly, studies started making sense. The social side was still a work in progress, but academically something had started moving.

My father, meanwhile, decided to actively show some interest in me. This was not exactly what I had been asking for, because by then I had become very comfortable with my freedom.

At one point in eleventh standard, he took me to meet relatives whose children were preparing for IIT. I still find this hilarious. Here was a boy who had barely established a working relationship with the Tamil Nadu State Board syllabus, and my father apparently felt exposure to IIT preparation would be inspirational.

Then he made me write IIT-JEE, and my experience was remarkably similar to my eighth-standard entrance test. Another blank paper.

But that was also my dad in his own way. He may not always have been closely involved in the day-to-day details, but he kept trying to push me towards opportunities he believed could help me. Some were wildly optimistic, like IIT, but others became crucial.

By twelfth standard, something had changed in me. Thanks largely to my mathematics teacher, I had finally understood that this was a make-or-break period. I became serious. I would study until midnight or one in the morning, wake up early and go to tuition at five, write tests at odd hours and repeat the cycle.

Mathematics suddenly became natural to me. I began competing for the first rank in maths and consistently did very well. Maybe some of it came from my grandfather, who was excellent at mathematics, but there was also a lot of hard work because I knew I was compensating for years of weak foundations.

I used to drink four glasses of coffee at night to stay awake, and my mother would make fresh coffee and leave it for me.

We were living in a single-bedroom house, and our house was always full — full of people, full of conversations, full of opinions and, as I said earlier, full of drama. Finding a quiet place to study required some creativity. My favourite spot became the terrace, sitting between two water tanks. It was relatively cool, relatively quiet and, most importantly, nobody wanted that particular piece of real estate.

At that time, some of the chaos around me probably affected me more than I realised. Looking back now, though, I see it differently. It taught me how to find my own space, create my own routine and get on with what I needed to do even when the conditions were far from perfect.

Then, just before my maths board examination, I developed a fever of around 104. I was completely down. That day gave me a childhood memory I still carry very clearly — my father quietly sitting beside me, placing a cold wet towel on my forehead and taking care of me.

I went to the examination with the fever and scored 100% in mathematics. That was probably my first real claim to fame.

My tuition teacher was incredibly proud. Even years later, whenever I met him, he would introduce me as his first centum student. Thinking about that still makes me emotional.

My other subjects were not spectacular, and I ended up with around 83% overall. For where I had come from, I thought it was a massive achievement. It was not enough to get the engineering seat I wanted through the normal route, but my father found a way to get me into a good college in Chennai.

That was one of those moments where his support changed the direction of my life. When I look back now, I know that even though he was not always actively present in the way I might have wanted as a child, many of the opportunities that shaped me would simply not have happened without him.

College was fun. I had friends and had started becoming a little more city-bred, but once again I discovered how large the gaps were between me and some of the people around me. There were students who seemed to understand subjects much more deeply. Some spoke English effortlessly. Some were confident in situations where I was still hesitant.

I continued doing very well in mathematics and was the topper in maths for several semesters. That gave me confidence, and then I would meet some genuinely brilliant classmate and the confidence would get adjusted again. It was useful calibration. I was academically strong in certain areas, but still raw.

The real break came in final year. One of our lecturers was arranging project opportunities at LRDE in Bangalore, which was associated with DRDO, and I raised my hand immediately.

When I think about it now, maybe that was the same curious boy who had once stood around a radio in UKG without understanding a word of cricket commentary. I had heard so much about Bangalore by then and desperately wanted to see the place for myself. The LRDE project sounded technically interesting, but just as importantly, it was in Bangalore. That was enough for the Curious George in me. I wanted to go, explore, see what the city was like and find out what this opportunity would lead to.

That curiosity has stayed with me all my life.

Bangalore became my first serious taste of independence. I stayed at a friend’s aunt’s house and, to my own surprise, adapted very well. I was disciplined, kept my things organised, maintained routines and handled myself responsibly.

Some of those habits came from home. My father, in particular, was extremely disciplined about how he presented himself. I never once saw him go to office looking shabby. He did not have the luxury of expensive clothes, but he always dressed impeccably and carried himself with a certain neatness and dignity. I picked up more of that from him than I probably realised at the time.

I also did extremely well in the project. My confidence shot up, and maybe I thought I was finally becoming sophisticated.

Life corrected that assumption quite quickly.

After college, I joined a company as a trainee. They had a three-month training programme and would absorb people based on performance. Technically, I did reasonably well. Personally, I was still me. I spoke whatever came to my mind and had not yet learnt that being correct and being effective are not the same thing.

I was not absorbed.

That was a huge blow. Suddenly, I had no job. Most of my friends were placed, while I remained unemployed for nearly a year after that stint. I was distraught, but by then I also knew I had made mistakes. I had to learn not only technically, but also how to behave, communicate and operate in a professional environment.

Then my next opportunity came, and it took me to Bombay.

I did not know it then, but that city would become the first real turning point in the way I worked, lived and saw myself.

That is where the next part of this story begins.

Continue to Part 2: Life Is a Work in Progress: Becoming

Over the years, I have had a habit of trying to hold on to people. If someone was close to me and then slowly moved away, I found it difficult to accept. I would try to reconnect, understand what had changed, revive the old warmth and sometimes put in far more effort than I should have.

For a long time, I saw this simply as people leaving.

Only recently, I started looking at it differently.

I have begun to feel that God brings some people into our lives for a reason. They may stay for a few years, sometimes for a very short period, and during that time they may change something important in our life. Once that happens, the relationship may continue, it may change, or the person may slowly move away.

I have started thinking of such people as planted people.

The phrase itself probably stayed with me because of a dialogue from Thevar Magan that I have remembered for years. The idea in that scene was simple: we may sow something today and may never live to see what grows from it. Someone else may see the fruits much later. Over time, I have started seeing people in my own life in a similar way. Some of them planted something in me without ever knowing what it would eventually become.

When I look back at my own life, I can count many of them.

One of the earliest was someone in my family whom I was extremely close to. I lost her when I was still quite young. She was a working woman who carried a lot of responsibility, but what stayed with me was the way she handled all of it with a smile. Years later, I realised that watching her had shaped my belief that women should work, build their own identity and be financially independent. She never taught me any of this directly. I simply saw the way she lived, and something stayed with me.

There were others who influenced the direction of my life in very different ways. Someone played an important role in bringing our family to Chennai, another helped me get into engineering at a crucial stage, and someone else helped me get my first job. What surprises me now is that I do not properly remember many of them, but I clearly remember what those interventions did for me. Each one opened a door, moved me into a different stage of life, and gave me more confidence to keep moving forward. Looking back, I can see how these connected events shaped a large part of my personal and professional journey.

Most of them may never have known what happened after their intervention, or how important the door they opened eventually became for me.

There was also a manager I worked with in the US very early in my career who became a mentor to me. He took me under his wing, coached me on how I should work, how I should conduct myself professionally, and helped shape the way I approached my career. That phase eventually passed and he too drifted away from my life, but his mentoring did not. Even today, I can see parts of what he taught me in the way I work and in the way I guide others.

Some planted people open a door for us. Some help us walk through it. And some quietly shape the person who eventually comes out on the other side.

Another person, during a different phase of my career, helped create an opportunity for my wife and me to live and work in the same location. It may have been a simple professional decision for him, but for us it made a very big difference at that point in our life.

There was also someone who entered my life during a very difficult period. She noticed something unusual about my health and strongly encouraged me to get it checked, which eventually led to the discovery of a serious medical issue. She stayed connected with me for nearly a few years after that and supported me through that period in many ways.

I have always felt that she came into my life at exactly the right time, as designed by God.

Of course, planted people are not the only ones who shape us. The people who continue to live around us — our family, friends, colleagues and others who are part of our daily life — influence us constantly as well. In many ways, who we are today is a mix of all these influences, both from the people who stayed and from the people who came into our lives only for a period.

What feels different about planted people is that their presence often seems connected to a particular phase, need or turning point in life.

Some of them do more than change the direction of our journey. They leave a part of themselves in us.

I have had elders in my life who influenced me deeply. One taught me, mostly through his actions, that I should always try to be just. Another always called a spade a spade and did not change his position depending on who was involved. There were others who left behind different qualities, values and ways of looking at life.

Over time, these influences become part of us. We may not even consciously remember where a particular quality came from. It simply becomes part of who we are.

That thought brought me back to the person I lost when I was young. She never got to see how much her way of life influenced me. Today, my children have grown up watching their mother work and build her own career, and they have also grown up seeing me support that. Perhaps something I picked up from someone many years ago is now quietly being passed on to the next generation.

That is when this thought came to me very strongly:

The planted person never really sees the tree grow.

The people who helped me at different stages of my life probably never knew what grew from those interventions. The elders and mentors who shaped some of my values did not get to see all the situations in which those values later guided me.

And then I started wondering about the other side of this.

If so many people were planted in my life, is it possible that I too have been planted in someone else’s life?

Maybe I said something to someone at the right time. Maybe I gave someone an opportunity, encouraged someone when they were doubtful, or helped someone take a decision. I may never know, just as many of the people who influenced me probably never knew what happened afterward.

That thought gives me a strange sense of happiness.

This way of looking at people has also changed something in me. Earlier, if someone mattered to me, I somehow felt that the relationship had to remain the same. I would keep trying to bring it back even when life had clearly moved on.

I still believe relationships need effort. Sometimes we have to reach out, repair misunderstandings, forgive and try again. But I am slowly learning that not every meaningful relationship has to remain unchanged forever.

Some people stay. Some move away. Some leave us completely. But that does not erase what they brought into our lives.

These days, when I think about someone who is no longer part of my everyday life, I ask myself a simpler question.

What did this person leave in me?

And sometimes I wonder whether someone, somewhere, is asking the same question about me.

There are evenings that pass unnoticed, quietly blending into the routine of everyday life, and then there are a few that unexpectedly make us stop and look at ourselves differently. I experienced one such evening recently while walking on the terrace. I had walked there many times before, usually occupied with thoughts about work, family, responsibilities or something that needed to be done the next day. That evening was no different until, for no particular reason, I looked up and found myself staring at the moon.

I have seen the moon thousands of times in my life, but something about it held my attention that evening. As I continued walking, a simple thought entered my mind: the moon was there when I was born. It was there during my childhood, through my student years, when I started working, when I got married and when I became a father. It has silently watched every phase of my life, just as it watched countless lives before mine. Long after I am gone, it will continue to be there, watching generations that have not even been born yet.

That thought began to snowball. The moon itself is only a tiny part of our solar system. Our solar system occupies an almost insignificant place in the Milky Way, and our galaxy is merely one among an unimaginably large number of galaxies in the universe. Against that scale, what am I? What are any of us? We are not even a speck, and our individual lifetimes are barely a moment in the enormous passage of time.

Yet, for beings who occupy such an insignificant place in this universe, we carry an extraordinary amount of ego. We hold grudges, nurture anger, remember insults and sometimes spend years wanting to prove someone wrong. We replay conversations long after everyone else involved has forgotten them. We carry the desire to win arguments and establish that our way of seeing the world is the right one. Standing beneath something that had existed long before me and would continue long after me, much of that suddenly seemed almost absurd.

I found myself wondering why we carry so much weight through such a short life. Today itself is a gift. Tomorrow, if it comes, is a bonus. I have known this intellectually for years, but knowing something and living according to it are very different things. Life had given me a reality check a few years ago through an event that reminded me how quickly everything we take for granted can change. Yet here I was, years later, still allowing relatively small things to occupy far more space in my mind than they deserved.

As these thoughts went through my mind, I began hearing the voices of the people who know me better than anyone else. My family has actually been giving me feedback for years. Perhaps I heard the words but never really listened to what they were telling me.

My daughters have been telling me for some time that I need to loosen up. “Dad, just go with the flow. Just chill. You don’t have to solve everything,” they tell me. They remind me that I don’t have to be practical all the time and that not everything needs my opinion or an answer. I usually laugh when they say this, but standing under the moon that evening, those words began to sound less like casual teasing and more like feedback I should have listened to.

All my life, I have tried to be the friendly dad—the father my daughters could confide in, joke with and disagree with. I think we still share that relationship; when something really troubles them, they often come to me, and we continue to have our share of jokes and terrible PJs. But perhaps being dependable and being easy-going are two different things. My daughters have been asking me for more of the latter, and I think it is time I listened.

My wife has been telling me much the same thing in her own way. She has often pointed out that I like things to happen in a particular way—usually my way—and that when they don’t, I can lose my patience. She too has repeatedly told me that I need to become more easy-going. Coming from someone who has watched me navigate life at close quarters for so many years, perhaps that feedback deserved far more attention than I had given it.

For a long time, I interpreted all of this as the inevitable consequence of being responsible. Taking responsibility has been part of who I am for most of my adult life. If something needs to be done, my instinct is to own it, think through what could go wrong and make sure it gets done properly. At home, that often meant looking ahead, anticipating problems and trying to protect the people around me from avoidable mistakes.

Standing under the moon, however, I began to see the other side of that instinct. Somewhere along the way, taking responsibility had made me feel responsible not only for what needed to happen, but also for how everyone around me should make it happen. Concern became advice, advice became instruction, and instruction sometimes became criticism. Because I believed I was helping, I didn’t always notice when help had turned into interference.

Perhaps I had become a critic without ever intending to become one.

That was difficult to acknowledge because much of it came from caring deeply about the people around me and feeling responsible for their well-being. But good intentions do not automatically create good experiences for the people receiving them. Love and control can perhaps look remarkably similar to the person expressing them while feeling very different to the person receiving them.

Maybe they have a point. Instead of explaining why I am the way I am—as I probably would have done earlier—I think I should simply take the feedback and work on it. After all, when three people at home are telling you pretty much the same thing, the odds are probably not in your favour.

Over the years, I have also noticed something in my wife that I increasingly admire: an ability to let go, to accept things that cannot be controlled and to choose peace more easily than I can. Perhaps I noticed that quality without fully understanding what it was trying to teach me. She had been telling me to become more easy-going. My daughters had been telling me to chill. Different words, different generations, but perhaps exactly the same message.

And now the moon seemed to be telling me the same thing without saying a word.

As I continued walking, another thought occurred to me. How many people must have looked at this very moon over thousands of years? Millions, perhaps billions, of people must have stood beneath it carrying their own grief, anger, confusion, regret, love and hope. Someone after losing a person they loved, someone after an argument, someone after falling in love, someone while facing an impossible decision. I wondered how many of them had looked up searching not necessarily for answers, but for clarity.

The moon must have silently watched every one of them. It never offered a solution, never corrected their thinking and never insisted that there was a more practical way of handling their problems. It simply remained there, quietly present, while each person had a conversation with themselves. Perhaps some walked away without answers. Perhaps others discovered that the answer had been inside them all along and that they simply needed enough silence to hear it.

That thought connected everything for me.

Maybe I don’t need to take responsibility for every outcome around me. My daughters don’t always need their father’s solution. My wife doesn’t always need my practical assessment. My parents and in-laws don’t always need to be told how something could be done better. Sometimes the people we love simply need a sounding board—someone who will listen without judgement and give them enough space to discover their own answers.

Perhaps that is something I can learn from the moon.

I don’t want this realization to turn me into someone who no longer cares or avoids responsibility. Nor do I want to stop speaking my mind or abandon convictions that matter to me. What I do want to learn is where my responsibility ends and another person’s life begins. Offering guidance is different from owning the outcome, and loving someone sometimes means trusting them enough to make choices I would not make myself.

There is another part of this that I am beginning to understand. Perhaps the change I need is not to become a different person, but to learn to adapt the person I already am. The qualities that served me well in one phase of life may need to evolve in another. The world around me is changing, my daughters are growing up and all my relationships are evolving. I can’t remain stubbornly stuck in the same version of myself and expect everyone else to adjust. I need to adapt too.

I am under no illusion that one evening with the moon has suddenly transformed me. I will probably offer an unsolicited solution before this essay is even published. Habits built over decades aren’t going anywhere that easily. But at least I am beginning to notice them.

As I enter the second half of my life, that adaptability matters to me more than it once did.

Years from now, I hope my daughters remember a father who was willing to listen when they challenged him and willing to change when he realised they had a point. I don’t want to grow older believing that age and experience automatically make me right. Perhaps that is another responsibility I need to take seriously—not the responsibility to shape everyone around me, but the responsibility to keep reshaping myself.

I still want to be the person my daughters can reach out to about any decision in their lives, without the inhibition that I will immediately tell them what they should do. I want to listen, understand and offer my perspective when they need it, while leaving the decision where it belongs—with them. Perhaps that is the kind of sounding board I need to become: present without directing, available without taking over. A little more like the moon that evening—quietly present, giving me the space to find my own answers.

The moon will continue to be there long after all of us are gone. It will silently watch generations after ours wrestle with the same emotions, relationships, egos and questions that we wrestle with today. It will probably continue doing exactly what it did for me that evening—nothing at all.

Perhaps that is its lesson. It does not provide answers, take responsibility for anyone’s choices or pass judgement. It simply stays there, quietly providing the space for a conversation.

That evening, I thought I was having a conversation with the moon. Looking back, I realise that the moon was simply being a patient listener while my family, my experiences and my own heart did all the talking.

For once, I listened.

In one of our product workflows, we made what initially seemed like a natural architectural choice. We allowed an agent to decide how the workflow should proceed. Based on the conditions it encountered, the agent used an LLM to reason about the situation and determine the next step.

The approach was attractive. Instead of modelling every decision explicitly in deterministic logic, we could allow the agent to interpret the context and choose the appropriate path dynamically. This was, after all, one of the promises of Agentic AI: moving beyond rigid automation toward systems that could reason and adapt.

The design worked reasonably well. But when we repeated the same decision enough times, we began to see the problem. The agent made the decision we expected roughly seven out of ten times. In the remaining runs, it chose differently.

The issue was not that the agent lacked reasoning capability. It clearly demonstrated that it could understand the conditions and arrive at the expected decision.

The problem was that we had given probabilistic reasoning authority over a part of the workflow where we expected predictable execution.

That experience forced us to reconsider a more fundamental question:

Just because an agent can make a decision, should it have the authority to make it?

Capability Is Not Reliability

There is a reason modern agent demonstrations are so compelling. The system does not simply answer a question. It can plan, select tools, adapt based on intermediate results, recover from failures and continue toward a goal.

When all of this comes together, the behaviour feels remarkably deliberate.

The danger is not that these demonstrations are misleading. Most of them work exactly as shown. The danger is the conclusion we tend to draw from them.

Because an agent reasons correctly once, we assume it will reason consistently. Because it successfully selects the right tool, we become comfortable allowing it to select tools dynamically. Because it explains why it took an action, we begin to trust the action itself.

But a successful execution demonstrates capability. It does not establish reliability.

Enterprise reliability asks different questions. Will the system behave predictably across repeated executions? What happens when conditions change? Can we constrain what it does? Can we stop it? Can we understand why an action occurred and who was responsible for it?

Large language models make this distinction harder because even an incorrect action can arrive with a convincing explanation. Traditional software failures often announce themselves through exceptions, validation failures or alerts. An agentic failure can arrive wrapped in a coherent narrative.

Fluency can make an action appear more reliable than it really is.

Better models will certainly improve this. Reasoning will improve. Tool selection will improve. The percentage of correct decisions in scenarios like the one we encountered may rise considerably.

But that does not remove the architectural question.

Better intelligence does not eliminate the need for control. It changes the level of autonomy we may be willing to grant.

Autonomy Is an Architectural Choice

Autonomy is often discussed as though it were an intrinsic property of an AI system.

I think that framing hides something important.

Autonomy is not something a system has. It is something we allow.

A model may be capable of reasoning about a situation. An agent may be capable of selecting tools, planning multiple steps and adapting its execution dynamically. None of those capabilities automatically determines how much authority the system should have.

Authority is an architectural choice.

This is where autonomy can easily become inferred rather than engineered. An agent successfully selects the right tool several times, so we allow it to select tools dynamically. It determines the right next step, so we allow it to control more of the workflow. It successfully recovers from a failure, so we allow it to retry autonomously.

Gradually, the boundary moves because the agent demonstrates capability rather than because we explicitly decided where that boundary should be.

Our 7/10 experience exposed precisely this problem.

We had given the agent autonomy over part of the execution flow. In doing so, we had also transferred control of an important workflow decision to probabilistic reasoning.

We eventually moved control of that part of the workflow back into deterministic system logic and allowed the agent to reason within a more bounded context.

The lesson was not that probabilistic reasoning had no place in the workflow. That would defeat much of the purpose of introducing agents in the first place.

The lesson was simpler:

The ability to make a decision does not automatically justify the authority to control the flow.

Tool Access Is Not Decision Authority

The same distinction applies to tool use.

An agent may have access to a registry describing the tools available to it and the capabilities each tool provides. The LLM can reason about the task, determine which capability it requires and invoke the appropriate tool.

There is nothing inherently wrong with this. Dynamic tool selection is one of the useful characteristics of agentic systems.

The architectural question becomes more important when those tools can change enterprise state.

An agent that can query logs, inspect metrics and search documentation can reasonably be given considerable freedom to explore. If its available capabilities also include changing a business record, approving a transaction, restarting a service or triggering a downstream process, access alone should not determine authority.

The problem is not necessarily that the agent will make an obviously irrational tool call. Each action may appear reasonable when viewed in isolation. But probabilistic reasoning can produce a sequence of individually plausible actions whose combined effect was never intended.

The agent can be locally rational while the resulting system behaviour is globally undesirable.

This is why giving an agent access to a capability is not the same as giving it unrestricted authority to use that capability.

The boundary might be enforced through workflow state, policies, authorization, approval thresholds, constraints within the tool itself or human intervention. The implementation will vary.

What matters is that the boundary is deliberate.

AI Agent Autonomy, Control and Trust

This brings me to three terms that are frequently collapsed into one conversation.

Autonomy is the ability of a system to act without constant human instruction.

Control is our ability to constrain, interrupt, redirect or audit those actions.

Trust is different from both.

Trust is not a capability we configure. It is a conclusion we reach after observing sufficiently predictable behaviour over time.

Greater autonomy therefore does not automatically create greater trust. In some situations, increasing autonomy without corresponding control can do exactly the opposite.

This is also why I do not see this as an argument against Agentic AI.

There are many places where we should give probabilistic intelligence room to operate. Let the agent explore possibilities, interpret ambiguous information, investigate unfamiliar conditions and dynamically determine how to solve a problem. Trying to model all of that deterministically would remove much of the value we are trying to create.

The architectural mistake is assuming that open-ended reasoning must automatically result in open-ended control.

The more useful question is where intelligence should have freedom and where consequences require explicit boundaries.

Those boundaries can evolve. As models improve, evaluation becomes stronger, observability increases and systems demonstrate predictable behaviour over time, we may become comfortable granting greater autonomy.

Autonomy does not have to be static.

But it should be deliberate.

From Impressive Autonomy to Predictable Autonomy

I remain optimistic about Agentic AI. The ability of these systems to reason, adapt and interact dynamically with enterprise capabilities opens possibilities that traditional automation could not address easily.

But maximum autonomy should not be the objective.

Useful autonomy should be.

That requires us to distinguish capability from authority, autonomy from control, and coherent behaviour from reliable behaviour.

Enterprises do not need agents that merely feel intelligent.

They need systems that behave reliably.

Perhaps the more useful question for Agentic AI is therefore not “How autonomous can we make this agent?”

It is:

“How much autonomy should this system have, and where should that autonomy stop?”

In the first article of this series, I wrote about how AI forced architectural precision — ambiguity could no longer hide in high-level documents. In the second article, I explored what happens when that precision turns architecture into specification that feeds implementation directly. This article is about something more fundamental: where good architecture actually comes from.

It does not come from consensus. It does not come from best practices applied mechanically. It does not come from a senior architect prescribing a design that everyone agrees to because no one wants to challenge it.

Good architecture emerges through resolved tension.

The Myth of the Clean Design

There is a persistent myth in our profession that good architecture is the product of clear thinking by a skilled architect. The architect studies the problem, applies experience and patterns, and produces a design. The design is reviewed, approved, and handed to engineering.

That is how architecture is presented. It is rarely how architecture actually happens.

In practice, every meaningful architectural decision involves competing concerns. Performance pulls against simplicity. Isolation pulls against operational cost. Flexibility pulls against governance. Reuse pulls against autonomy. Every decision sits at the intersection of forces that do not naturally resolve themselves.

The architect’s job is not to avoid that tension. It is to resolve it — deliberately, with reasoning, and with full awareness of what is being traded away.

Tension Is Not a Problem. It Is the Process

Most architecture processes treat tension as friction — something to be minimised. Disagreements are resolved through compromise, through escalation, or through the most senior person in the room asserting their preference. The goal is alignment. Get everyone on the same page and move on.

That approach produces architecture that is politically safe and technically mediocre.

The alternative is to treat tension as the mechanism through which better decisions emerge. When two valid approaches compete, the debate itself — if conducted with rigour — forces both sides to articulate assumptions, expose trade-offs, and defend consequences. The decision that survives is not the one that was louder or more senior. It is the one that held up under scrutiny.

This is not a new idea. It is how engineering has always worked at its best. What changes with AI-assisted architecture is the speed and depth at which that tension can be explored.

What Resolved Tension Looks Like in Practice

Over the course of our architecture sprint, every significant decision went through a cycle of proposal, challenge, defence, and resolution. Not every challenge led to a change — some decisions survived intact. But they survived because they were tested, not because they were assumed.

A few patterns emerged in how these competing forces shaped the architecture.

Abstraction versus justification. A component would be proposed because it seemed architecturally logical — the kind of box that belongs on the diagram. The challenge was always the same: what does this component actually do that nothing else does? If the answer was vague, the component either earned a precise responsibility or it was removed. Architecture by convention — “every platform needs one of these” — did not survive. Architecture by justification did.

Completeness versus usability. There is a natural instinct to make architecture documents comprehensive. Cover every scenario, document every edge case, model every interaction. The pull in the other direction is that no one reads a 142-page document. The resolution was not to choose one over the other — it was to restructure so that completeness existed for reference while usability existed for daily engineering work. The same content, organised for two different audiences.

Flexibility versus governance. This is the oldest debate in enterprise architecture — how much freedom do you give teams versus how much you constrain? In an AI-assisted workflow, this becomes sharper because AI agents are capable of operating with significant autonomy. The resolution was not to pick a side. It was to define bounded execution contexts where autonomy operates within governed constraints. Freedom within fences.

Ideal design versus pragmatic delivery. The architecturally pure approach is not always the right one for v1. A design that is correct for scale may be over-engineered for the first release. The resolution was to design for the target state but implement for the current state — with an explicit migration path documented in the architecture. The pragmatic decision does not contradict the architectural vision. It sequences it.

The architect’s conviction versus the collaborator’s challenge. Some decisions came from deeply held architectural convictions — positions built over years of production experience. The temptation is to treat these as settled and move on. The better approach was to let them be challenged thoroughly, even when the conviction was strong. A principle that survives rigorous challenge is stronger than one that was never questioned. And occasionally, the challenge revealed an edge case or a nuance that the conviction alone had not accounted for.

Why This Matters More Now

In a traditional architecture process, these competing forces are resolved slowly. Debates happen in workshops, in review meetings, in hallway conversations over weeks. By the time a decision is made, the context has shifted, the participants have moved on, and the rationale is partially lost. Decisions are recorded as outcomes, not as resolved deliberations. The ADR says what was decided — it rarely captures the full weight of what was considered and rejected.

With AI in the loop, the resolution cycle compresses. A competing concern can be identified, debated, stress-tested, and resolved in a single session — with full context, full traceability, and full documentation of the reasoning. The decision is not just recorded. The deliberation that produced it is preserved. That matters because when the system evolves and someone asks “why did we do it this way,” the answer is not just “because the architect decided.” The answer is “because we considered alternatives A, B, and C, challenged each from these angles, and this is why the chosen approach held up.”

That is a fundamentally different quality of architectural decision-making. Not because the decisions are better in isolation — but because the reasoning behind them is visible, defensible, and transferable.

Architecture Is Not Designed. It Is Resolved

Looking back across the entire series, this is the thread that connects everything.

Part 1 was about precision — AI forced the architecture to be explicit because ambiguity could not survive the collaboration. Part 2 was about consequence — that precision turned architecture into specification that shapes implementation directly. This article is about origin — the architecture did not arrive through top-down design. It arrived through competing forces that were identified, explored, and resolved with rigour.

The best decisions in our architecture are not the ones I got right on the first pass. They are the ones that were challenged hardest and survived. The components that earned their place did so by proving their value in interaction patterns, not by looking correct on a diagram. The principles that held up did so because every counter-argument was explored and answered, not because they sounded authoritative.

This is not unique to AI-assisted architecture. It is how good architecture has always worked when it works well. What AI changes is the economics. The cost of rigorous challenge, deep cross-referencing, and thorough exploration of alternatives used to be measured in weeks of workshops and review cycles. Now it is measured in hours of focused collaboration.

The discipline was always available. The competing forces were always there. What changed is that resolving them thoroughly is no longer impractical.

And once you experience architecture that emerges through resolved tension rather than assumed correctness, it is very difficult to go back.

The Craft Remains. The Friction Does Not

The tools have changed. The economics have changed. But the craft remains the same — make decisions that hold up, challenge the ones that do not, and never stop questioning whether your architecture earns its place.

That is the job. It always has been, and it always will be. The difference now is that architects are supercharged. The impracticals that held us back — the cost of maintaining rigour, the effort of cross-referencing decisions, the time it took to explore alternatives thoroughly — are no longer barriers. AI is there to assist and aid. What remains is the architect’s full ability, finally unleashed without the friction that used to dilute it.