When You Can't Find Your Why: Surviving the Cloudy Nights

They say-- follow the North Star, have a strong "Why," and that will carry you through tough times. Find your purpose. But what if you don't have one—not yet?

Finding your why might take a day, a month, or a lifetime. But you can't wait for clarity to survive. You still have to live through the fog, the cloudy nights when the North Star is invisible. So how do you keep going?

---

The Purpose Paradox

I've read Man's Search for Meaning, Start with Why, and others in this genre. They all point to the same observation: people who survived hardship—concentration camps, personal crises, career plateaus—seemed to have something in common. A reason. A why. A sense that their suffering meant something.

Viktor Frankl's account of surviving Auschwitz emphasizes this: the prisoners who held onto a sense of meaning—whether reunion with loved ones, unfinished work, or spiritual belief—seemed to fare better psychologically than those who saw no reason to continue. Simon Sinek builds on this in Start with Why, arguing that organizations and individuals with a clear purpose outperform those without one.

The logic is compelling. And it's probably true: if you have a strong why, then you're more equipped to handle the difficult times.

But there's a gap in this narrative. What about the person who doesn't have that why yet? What about the gap between now and the day the lightbulb goes on?

---

Survival Without a North Star

David Goggins is famous for his relentless drive. But watch more of his interviews, and he says something that doesn't make the highlight reels: sometimes you have to keep going even when you don't feel passionate. Even when the fire isn't there. The skill isn't finding your passion—it's functioning without it.

That's different from what most motivational content preaches. Most says: "Find what you love, and you'll never work a day in your life." Goggins is saying the opposite: "Learn to work on days when you don't love it. Master that, and everything else becomes easier."

There's a line in The Boy, the Mole, the Fox and the Horse that captures this better than most productivity advice. The Boy says he's scared, that he can't see the way forward. And the Horse asks: "Can you see the next step?"

Not the finish line. Not the destination. Just the next step.

This is the antidote to paralysis in the fog. When you can't see your North Star, your ultimate purpose, or even where you're headed—you become a creature of the immediate. One step. One day. One small decision.

This isn't settling. It's not inspirational either. It's just... walking.

---

The Foundation Phase

Here's what nobody tells you: those years when you're "looking for your purpose" don't have to be wasted years.

You could spend five years soul-searching, reading, traveling, waiting for the clarity that will then let you get started. Or you could spend those five years building.

Do your work—the job, the side project, the relationships—with genuine effort. Not as a placeholder. Not as something to tolerate until the "real" purpose shows up. Do it as foundation-building. Because when your lightbulb moment arrives, you won't be starting from zero. You'll be starting from momentum. From habits. From the competence you've already developed.

The final blow that fells the tree is the one we remember. But 99 blows came before it—small, seemingly meaningless chips. The tree doesn't fall because of any single hit; it falls because of accumulated impact.

Think of a river carving a canyon. On any given day, the water moves the same volume of stone: imperceptible. Over decades, it rewrites the landscape. The water doesn't know it's creating something. It's just flowing, persistent, indifferent to grandeur.

You're the river. Do your work. Chip away. The landscape changes as a side effect.

---

When Purpose Shatters

But there's one more scenario the books don't address well: what if you had a North Star, and life knocked it down?

A financial crisis. The loss of someone you can't replace. A health diagnosis. A betrayal. These aren't mere setbacks—they're earthquakes that can collapse even the strongest sense of purpose. The "why" that got you through five good years suddenly feels hollow or impossible.

In these moments, purpose can't save you. Because your purpose is also broken.

This is where that unglamorous foundation matters most. If your entire resilience is wired to your purpose ("I do this because..."), then when the purpose disappears, so does the resilience. You're left with nothing.

But if you've practiced showing up on days with no grand meaning—if you've learned to chip away at the tree even when you can't see what you're building—you have a second tool. You're not relying on the broken North Star. You're navigating by the ground beneath your feet.

---

Living Well Without Answers

So here's what I think needs to be mastered: the skill of moving forward when you don't have all the answers.

It's not glamorous. There's no TED talk about it. But it might be the most practical resilience tool you'll ever develop.

Do your work. Do it with genuine effort. Treat this season—whether it's a month or a decade—as foundation-building, not time-wasting. Stay open to the moment when purpose crystallizes, but don't make your entire resilience dependent on it showing up on schedule.

Take the next step you can see. Chip away. Flow like water. And trust that the North Star will reappear—but also trust that you can walk through the night without it.

We spend a lot of time talking about how to find our North Star.

Perhaps we should also learn how to live when we can't see it.

Home Loan EMI - Expense or Investment ?

 I often hear people saying, “I earn XYZ, but after expenses — which also includes my home loan EMI — I have nothing left to save or invest.”

And I always wonder… isn’t the home loan EMI an investment too? Why do we automatically put it under “expenses”?

Maybe because we live in that house and can’t sell it whenever we want. But we are still building something for the future. Yet I have rarely heard anyone say, “I have ₹X invested in my house.” We usually say, “My expenses include ₹X of home loan EMI.” Same money going out. Different perspective.

Home Loan EMI — Investment or Expense?

Fit or Obsessed?

Going to the gym five days a week and spending hours training can be seen as dedication when yu are an athlete, but “obsession” when yu are just another person trying to stay fit. Again, same commitment, different interpretation.

Office Politics or Strategy?

Managing stakeholders, understanding people’s interests, building relationships and influencing decisions can be called “politics” when yu don’t benefit from it, but “stakeholder management” or “strategy” when yu are good at it. Maybe people who excel at it call it strategy, while people who suffer from it call it politics.

Personal Branding or Showing Off?

Sharing your wins online: a senior leader calls it ‘personal branding,’ but when yu do it, it’s ‘showing off.

Bribe or Gift?

A gift given to influence a decision can be called a bribe in one situation and a “strategic gift” or “relationship building” in another. Same exchange. Different label.

And then there is Workaholic or Passionate?

We see people who practice sports for hours — Virat Kohli, Serena Williams, Rafael Nadal — and call them passionate. They might be among the top 1% in their sport precisely because they put in that kind of effort.

Now at work, someone can be equally passionate about what they do. They don’t see everything as a strict 9-to-5. They put in extra hours, go beyond their role and genuinely care about the outcome. And we often call them a workaholic.

Why not passionate? Maybe not everyone wants to be an entrepreneur. Maybe some people simply enjoy contributing to a bigger goal by being really, really good at what they do.

Maybe that’s the interesting part about perspective. The action doesn’t always change. The label does.

And sometimes the label changes because of who is doing it, who is watching it, or simply whether it worked.

What is one example where yu have seen the same thing get a completely different label?

What if you had an AI assistant for the F1 rulebook?

This weekend, during Formula 1 free practice, Lewis Hamilton crashed and his front wing got stuck underneath the car. From the cockpit, he had no idea what happened. His team could see it and started warning him to stop. Within seconds, the commentator was already looking up the relevant regulations to understand what this meant for the rules. That moment stuck with me.

Try it out here: FIA Rules Assistant

I've watched F1 long enough to know that moments like this happen all the time — some dramatic incident unfolds, and you're left wondering exactly what the rulebook says about it. What if I had the full FIA rulebook sitting right in front of me, with an AI assistant that could actually help me find and understand the exact wording of the regulations, not just what commentators think it says? That seemed worth building.

So I gave myself a weekend goal: get a working RAG pipeline running publicly on AWS, put an interface in front of it, and see if people actually use it. Not perfect. Not a multi-agent masterpiece. Just end-to-end and functional.

When Cloud Means You Actually Have to Care About Everything

At work, there are teams, existing infrastructure, and security policies handling all the cloud complexity. This weekend project was different. I had to figure out IAM permissions, how services should talk to each other, where embeddings should live, which Bedrock models were available in my region, and how to make it all scale later. It was humbling.

The first big choice was embeddings. I could've kept things simple with local embeddings, but if the goal was a proper AWS pipeline, using Amazon Titan Embed Text through Bedrock made more sense. So I rebuilt the whole vector index around that. It meant more AWS dependency, but the production architecture became cleaner and more consistent — a trade-off worth making.

Then came compute. I didn't want to spin up an always-running EC2 instance just to power a chatbot. Lambda seemed obvious: pay only for what you use, and for a small app with sporadic traffic, that felt right. The FAISS index lives in S3 and loads when the Lambda fires up. Not perfect for scale, but perfect for a first version where simplicity wins.

Here's what the basic architecture ended up looking like:

Lambda cold starts are real, there are things I can't completely control about the runtime, and the FAISS approach obviously won't scale forever. But for a first version? It works.

ChatGPT, Some AWS Experience, and 12 Hours

I wanted to see how far I could get with ChatGPT instead of another coding subscription. It went further than I expected. ChatGPT generated a solid foundation for the RAG pipeline — ingestion, embeddings, retrieval, reranking, generation, Lambda wrapper, frontend, the whole thing. The real problems weren't about writing application logic. They were about connecting everything: finding the right AWS model identifiers, figuring out which Bedrock endpoints existed in my region, getting IAM right, making Lambda and API Gateway talk to each other, handling CORS, packaging it all in Docker. Once the basic code existed, I had ChatGPT walk me through AWS deployment step by step.

My previous cloud experience definitely helped. I wasn't learning from zero. But even so, it still took roughly 12 hours from that morning to having the first public version live. And honestly? Pretty fun weekend.

Then came launch day. I wanted to ship by 11 PM but got caught up in AI coding and deployment details. I skipped thorough retriever testing — assumed it would work since it did locally. When I pushed to cloud, it started timing out. What should have been 26 seconds per document retrieval was failing. Spent 3 hours debugging. Turned out my retriever code was tangled up trying to merge reranking and metadata filtering. Dropped both for this first release, got the latency down to 2 seconds, and shipped. They're coming back soon.

What's Actually Happening

Right now, this is a vanilla RAG system. A question comes in, the system finds relevant chunks from the FIA documents, reranks them, and the language model generates an answer grounded in those actual regulations — not guessing what it vaguely remembers. That matters when regulations are involved. You don't want confident-sounding nonsense. You want the rulebook.

The corpus is still small — regulations and International Sporting Code for now — but I'm building in metadata filtering for year, event, document type, session. That'll matter when I add race-specific material. You don't want a 2024 Abu Dhabi question competing with documents from 2020.

This Is Very Much a V1

There's no conversation history yet. No ReAct-style reasoning. No complex agents. But I actually wanted that. Better to have something that works, understand where it fails, and fix those pieces than build complexity too early.

I know ChatGPT, Claude, and other general-purpose assistants can already answer many F1 questions. That's not the differentiation I'm chasing. The real goal is making this genuinely F1-aware — connecting regulations with actual races, steward decisions, penalties, eventually race stats and telemetry. Long way to go, but the first step is live.

What's Next

I want to add a proper reasoning loop. Then improve retrieval before adding anything complicated. After that, imagine asking "Why was a driver penalized at race X?" The system could retrieve the steward's decision, identify which regulation it cited, go back and retrieve that exact provision, then return: what happened, what the stewards decided, which rule applied, what that rule says, and why it led to that decision. That's agentic RAG, not just chatbot stuff.

Try it out here: FIA Rules Assistant

It's independent and not affiliated with the FIA. But if you follow F1 and use it, I'd genuinely love to know what you'd want next.

10-Minute Agent !

 

What if AI agents could be delivered like groceries?

India has become fascinated with the idea of 10-minute delivery. Groceries, food, stationery, medicines, house help and a growing list of other services are being pushed toward the same promise: I need something now, and I don’t want to wait.

Some of these use cases are convenience plays; others, such as rapid ambulance or emergency-response services, can have a much more meaningful impact.

That got me thinking about a slightly crazy startup idea:

Why not a 10-Minute Agent?

I don’t mean that we magically build a sophisticated enterprise-grade agent from scratch in ten minutes. That would be a rather optimistic sales pitch! 😄

What I mean is: what if we could make the journey from “I need an AI capability” to “I have an AI capability deployed” dramatically faster and more configurable than it is today?

Think of it as an AI delivery network

Today, when a company wants to implement an AI solution, the journey can still be surprisingly long — requirements, architecture, model selection, POCs, data integration, security reviews, development, testing, deployment and plenty of back-and-forth.

The technology has become incredibly fast. The deployment process often hasn’t.

So imagine a different model. A customer comes to the platform and describes what they want to achieve. Instead of being handed one fixed “AI agent”, they get to configure the solution — choosing the model, data sources, capabilities and the trade-offs that matter to them.

OpenAI, Anthropic, an open-source model or their own? Documents, databases, APIs or a combination? Simple RAG, RAG + analytics, tools and workflows, or a more sophisticated agentic system? And then the inevitable trade-offs: cost vs performance, latency vs intelligence, managed vs self-hosted, simplicity vs flexibility.

In essence, the customer gets to configure their AI stack rather than buy a one-size-fits-all solution.

And this is where I find the idea particularly interesting. Instead of expecting the customer to figure out how to assemble and deploy all of this themselves, Forward Deployed Engineers become the delivery partners.

The platform takes the requirements and configuration, assembles the required components, and the FDE takes it the final mile — integrating systems, connecting data, handling customisation and edge cases, and getting the AI solution deployed.

In other words:

Maybe Dell had part of the answer

This is where an old idea came to mind. Years ago, Dell made PC buying interesting by letting customers configure their machine rather than forcing everyone into one fixed specification. You could choose the processor, memory, storage and other components based on what you actually needed.

What if enterprise AI worked the same way?

Instead of “Here is our AI agent. This is how we built it. Take it or leave it,” the experience could be: “Configure your AI.”

Choose the model, data, capabilities, infrastructure and the trade-offs you are willing to make — and let the platform recommend the right configuration.

For one business, that might simply be Vanilla RAG for answering questions over documents. For another, RAG + Analytics to combine unstructured documents with structured business data. Another might need RAG + Tools + Workflow to retrieve information, call APIs and execute defined processes. And for more complex problems, it could evolve into a fully agentic system capable of handling multi-step tasks.

The important part is that the customer doesn’t need to understand how every piece fits together. They describe the problem and the outcome; the platform translates that into the technical configuration, and the FDE turns it into a working solution.

That, to me, is where the Dell analogy gets interesting: don’t just sell the AI — let the customer configure it for what they actually need.

And this is where “10-Minute Agent” comes back

This is where I think the analogy with 10-minute delivery becomes even more interesting. A 10-minute delivery company doesn’t manufacture the grocery you ordered in ten minutes. The product already exists. What the company has really built is an infrastructure around selection, fulfilment and delivery that makes the entire experience incredibly fast.

Could AI deployment eventually work in a similar way?

The models already exist. OpenAI, Anthropic and a growing ecosystem of open-source models are already available. The databases and vector stores exist. The agent frameworks exist. Cloud infrastructure, APIs, observability and all the other building blocks required to put an AI system together are increasingly becoming commodities or readily available services.

So perhaps the challenge isn’t that we don’t have the ingredients.

Perhaps the challenge is getting the right ingredients together, in the right configuration, for the right business problem — quickly.

That is where the idea of a highly standardised configuration + orchestration + deployment layer becomes interesting. Instead of building every AI solution from scratch, the platform could bring together these existing components based on what the customer actually needs, apply the appropriate trade-offs, and create a deployable solution.

In that sense, perhaps the real product isn’t simply “an agent.”

The real product could be the AI delivery infrastructure that makes getting the right agent into a business as easy and eventually as fast as ordering something online.

And maybe that’s what “10-Minute Agent” really means.

Not necessarily an enterprise agent magically built from scratch in ten minutes — but an AI delivery system designed from the ground up to make that journey dramatically faster, more configurable and more repeatable.

Press enter or click to view image in full size

The FDE becomes the “delivery partner”

I also like the Forward Deployed Engineer part of this idea because it could fundamentally change both the economics and the operating model. If every customer requires a completely bespoke engineering team to build an AI solution from scratch, the business can very quickly start looking like a traditional consulting company — highly customised, highly people-dependent and difficult to scale.

But what if a large part of the architecture is already standardised, modular and configurable?

In that model, the FDE’s job becomes much more focused. They aren’t reinventing the entire solution for every customer. Instead, they take a pre-configured AI solution and make it work within the customer’s actual environment: connecting the systems, mapping the data, handling the inevitable edge cases, configuring authentication and permissions, adapting workflows, deploying the solution and helping the customer get it into production.

In some ways, they become the delivery partner for AI.

And there is another interesting possibility here. Every deployment can teach the platform something. The more customers you deploy for, the more integrations, patterns, reusable components, architectures and edge cases you accumulate. Over time, that knowledge can feed back into the platform, making the next deployment faster and requiring less bespoke engineering.

That is where the “10-minute” part starts becoming less of a marketing gimmick and more of a direction for the architecture.

If an AI deployment that takes months today can be standardised down to weeks, and then days, and then hours, perhaps some well-understood and highly repeatable use cases could eventually get down to minutes.

Maybe not every agent.

Maybe not every customer.

But perhaps enough of them to make “10-Minute Agent” a meaningful product philosophy.

Of course, there are some big problems

There is, of course, a rather large reality check here.

Enterprise AI isn’t quite the same as ordering a packet of biscuits in ten minutes. 😄 Data security, privacy, permissions, compliance, model quality, hallucinations, observability, cost management and integration complexity don’t disappear simply because we put a nice configurator in front of them.

Some deployments will always require substantial engineering. Some customers will need completely custom models, infrastructure or workflows. And some use cases will simply be too sensitive or too complex to automate in this way.

So I don’t think the objective should literally be “Every AI deployment takes 10 minutes.”

The more interesting objective might be:

“Make the default AI deployment experience feel as close to ordering something as possible.”

That is a very different proposition.

The ambition is not to pretend that enterprise AI is simple. It is to take everything that can be standardised, productised and automated — and make the remaining complexity as easy as possible for the customer and the FDE to handle.

So… a 10-Minute Agent company?

Maybe.

Maybe it is a terrible startup idea.

Maybe it is simply a fun thought experiment triggered by India’s obsession with 10-minute delivery. 😄

But the more I think about it, the more I wonder whether the next wave of AI businesses will be built not only around creating better models and smarter agents, but around making those models and agents dramatically easier to configure, deploy and customise for real businesses.

Because we already have most of the ingredients.

We have LLMs, RAG, databases, APIs, agent frameworks, cloud infrastructure and analytics. We also increasingly have Forward Deployed Engineers who can bridge the gap between the technology and the customer’s real-world environment.

What if we put a product layer on top of all of that?

A customer could come in with a business problem, choose the model and data sources they want, decide how sophisticated the solution needs to be, make the relevant cost-versus-performance trade-offs, and let the platform recommend and assemble the architecture.

Then the FDE takes over the last mile — integrating, customising and deploying it.

Choose what you need. Configure the trade-offs. Let the platform assemble the solution. Send the FDE to deliver it.

And eventually…

10-Minute Agent. 🚀

Just like 10-minute delivery didn’t really change what we buy — it changed how quickly we can get it — perhaps the opportunity in AI isn’t only to build more powerful agents.

Perhaps it is to build the delivery infrastructure for AI: the layer that lets businesses get the right agent, configured for their needs, integrated with their systems and running in production much faster than they can today.

From:

“We should build an AI agent.”

to:

“Your AI agent has been delivered.”

That, at least, sounds like a startup I would be curious to explore.