Who Knew Juggling Could Be This Interesting?

Have you ever tried juggling? At first glance, it looks simple enough: throw a few balls in the air, catch them, and repeat. But what if I told you that there is an entire world of mathematics, physics, specialised equipment, research, and experimentation behind this seemingly simple hobby? I certainly didn't know much about it when I started, and what began as an attempt to learn a few tricks turned into an exploration of something much bigger than I had imagined.

Over the years and decades, I have tried my hand at quite a few things. If you have read my earlier posts, you would know that coding, sports, and a whole lot of other activities have been part of that journey. One thing I have noticed is that whenever I pick up a new hobby, I don't always stop at learning the basics. I end up going down a rabbit hole, watching tutorials, reading about techniques, understanding the equipment, and trying to figure out how to do things better. Sometimes, that exploration becomes as much fun as the activity itself!

Take tennis, for example. When I was learning to play, I would go through tutorials on the best way to serve, how to move around the court, and how to improve different aspects of my game, and then try to put those lessons into practice on the court every day. Cycling was another such experience. There was so much to learn about gear shifting, cadence, different gear sets and frame designs, and even which specifications were permitted in racing and which weren't. I genuinely enjoyed getting my hands dirty, setting up the ideal riding position, figuring out the mechanics of the bicycle, and establishing weekly cleaning and maintenance routines. It was a lot of fun exploring all these little details that you might otherwise overlook when you simply take up a sport.

Everything was going fine until I picked up juggling! I had watched a couple of juggling performances at IIT Mood Indigo, and something about them hooked me. I thought it would be one of those hobbies where you watch a few YouTube tutorials, practise a handful of skills, and gradually get better. There was probably some history behind it, I thought, but I never imagined the sheer amount of research, mathematics, experimentation, and technical knowledge that people were putting into it. I had barely scratched the surface, and the more I explored, the more interesting it became. Before going any further, though, a big shout-out to my brother for getting me some high-quality juggling props from the UK. Having the right equipment certainly made the experience more enjoyable!

Video link --  First Juggling Show Unedited

Juggling also taught me something about how the eyes and body work together. You need a surprisingly good sense of peripheral vision, because you are constantly glancing at the balls, catching them, and throwing again without ever having time to follow any single object all the way. Or may be over time, juggling improves that peripheral awareness. Like most hobbies, it starts out very conscious: you think about every throw, where your hands are, and where the ball should go. With practice, those movements slowly sink in until they become second nature, and you no longer have to think about each individual throw. That is when you can finally focus on the pattern itself.

Let me share a few things that surprised me along the way.

Siteswaps: Yes, there is mathematics behind juggling

Did you know there is a way to write down juggling patterns and even check whether a sequence of throws is mathematically valid? It is called siteswap notation. Take the basic three-ball cascade, the pattern most people probably picture when they think of juggling. In siteswap, it is represented simply as 3, because each throw is followed by another throw of the same type. The number tells you how many beats later the ball will be thrown again. A beat here refers to one throwing opportunity, with the right and left hands alternating. So, a throw marked 3 will return to a throwing opportunity three beats later, allowing the pattern to continue.

Check out online animator here -- Siteswap animator

Now, what if you want to change things up? The sequence 5 1, for example, represents a three-ball shower pattern, where a higher throw is followed by a quick, low throw across to the other hand. The numbers are not just labels for tricks; they describe the timing and relative height of the throws. Once you understand the basics, you can start exploring different combinations and even use software to animate the patterns before trying them out yourself.

And this is where things get interesting. Not every sequence of numbers will produce a valid repeating juggling pattern. Siteswap notation gives you a way to analyse the sequence mathematically, checking whether objects will land at the right times without colliding. For example, 4 2 3 is a valid three-object pattern, while 4 3 2 is not a valid repeating pattern under standard siteswap rules. There is also a useful relationship between the average of the numbers in a repeating pattern and the number of objects being juggled. For 4 2 3, the average is three, which tells us that the pattern uses three objects.

Think about it for a moment: something that looks like a purely physical activity can be represented using a sequence of numbers, analysed mathematically, and visualised on a computer. I found that fascinating, and siteswaps are only one small part of the world of juggling.

Video -- Click to play

In the video I follow one Siteswap only - 333 -- although the pattern changes continuously as I change the throws..

Russian juggling balls: It's not just about throwing and catching

Another interesting discovery was Russian juggling balls. Most beginners start with juggling balls that are designed to be relatively easy to catch and control, often weighing somewhere around 100 grams, although the actual weight and diameter vary depending on the type of ball. You might also come across beanbag-style balls, which are soft and deform slightly when caught, making them less likely to roll away when you drop them.

Russian balls are different in their construction. They are generally hollow shells partially filled with granular material, which changes their weight distribution and how they behave when thrown and caught. Depending on the design, they can feel quite different from traditional beanbags or solid juggling balls. It is another example of how even something as seemingly straightforward as choosing a ball can become a subject of experimentation.

There are also a few technical details you start noticing when you practise regularly, and they are a useful way to check your timing. If you find yourself moving forward to catch the balls, you are most likely releasing them too early. If the balls keep landing closer to your body, you are releasing them too late. Most of the power and height comes from your elbow and arm, so when a throw is too high or too low, adjust the elbow and arm movement first, rather than trying to move your hands faster to catch everything.

Juggling clubs: Height, spin, and getting everything right

Once you move from balls to clubs, things get more interesting, but the basics actually become simpler. As with balls, the height of your throw comes from your elbow and arm. Clubs also need spin, and that comes from your wrist. So you control two things separately: the height through your elbow, and the spin through your wrist.

This gives you a few options. You can throw a club low with a controlled spin, or throw it high with more spin, and as you practise you will learn both. The real skill is controlling the essential parts, the height, the spin, and the catch, so that every throw is good enough to repeat. Get one throw right after another, and you have a pattern.

Video -- Click to play

What I particularly enjoyed was the way the learning works. You try something, observe what happens, make a small adjustment, and try again. Sometimes the problem is the height, sometimes the spin, and sometimes the timing. It is like running a series of small experiments, changing one thing at a time. If you enjoy understanding how things work, this can be just as rewarding as learning a new trick.

The people taking juggling to the next level

One of the things that surprised me most was discovering the people who were taking juggling beyond simply performing tricks. Niels Duinker was one of the jugglers whose YouTube tutorials I learnt from. His tutorials helped me understand the fundamentals and work on my skills, and it was interesting to discover his background as an engineer as well.

Then there is Jay Gilligan, a juggler and artist known for exploring juggling as a creative and experimental practice. His work goes beyond conventional tricks and performances, examining the objects, movements, and possibilities involved in juggling. This was another reminder that people approach juggling in very different ways. Some want to master the fundamentals, some want to perform, and others want to experiment with new techniques and challenge the boundaries of what is possible.

Youtube - Tech Talk by Jay Gilligan -- The evolution of juggling | Jay Gilligan | TEDxHelsinki

You also find people experimenting with different props, materials, sizes, shapes, and weights to understand how they affect the way a pattern is performed. The equipment is not merely something you buy and use; it can itself become part of the research and creative process. Watching or reading about such work makes you realise how much more there is to explore once you get beyond the basics.

And then there is the community around juggling, with international conventions, festivals, workshops, and competitions where jugglers meet, share ideas, learn from one another, and try out new things.

Back in the days when I was more actively pursuing this hobby, I would dream of attending one of these international juggling conventions myself! It would have been quite an experience to see so many people come together around something that most of us might otherwise regard as a fun party trick.

There is always more to explore

Looking back, I think that is what I enjoyed most about juggling. I started with the simple idea of learning to throw and catch a few balls, but along the way I discovered mathematical notation, the physics of throws, the differences between equipment, the importance of technique, and a community of people constantly experimenting with the art. I certainly did not become an expert, and there is plenty I never got around to exploring, but even scratching the surface was enough to appreciate how much depth there is behind the hobby.

It also reminded me of something I have experienced with many of the activities I have tried over the years. What you see on the surface is often only a small part of the story. Whether it is tennis, cycling, coding, or juggling, there is usually a whole world of knowledge and experimentation waiting for you once you start asking questions and looking a little deeper. You don't necessarily have to master everything or turn every hobby into a serious pursuit. Sometimes, simply discovering what lies beneath the surface is rewarding enough.

And who knows, perhaps I will get back to juggling more seriously someday, revisit some of those skills, and finally make it to an international juggling convention. Until then, there is always something new to learn, another pattern to try, or another rabbit hole to go down. After all, that is half the fun of experimenting with hobbies in the first place!

Finally -- below is another snap shot where I combine Juggling with Machine Learning (Object tracking) - combining two of my hobbies --

Video -- Click to play

PS -- Used good amount of Claude and chatGPT to bring flow and structure to the blogPost !

I miss -- wow Sandy, yu are awesome !

Grinding throughout the night and sometimes for days on end, and then finally, when the code is cracked — Wow Sandy — yu are awesome!

That is how my time used to be at work and at home too, on personal projects. I am sure I am not the only one, and yu would have experienced similar situations when, after banging your head over some problem, you finally crack it — yu finally crack the magician's code. And that euphoric moment — it can't be expressed in words.

Nowadays, whether it is an engineering problem, coding, or anything else, we tend to go to Large Language Models (LLMs) and it's products (ChatGPT, Claude, etc.) and ask them to reason, and we have become so impatient that we don't even stop to think or try to solve the problem at hand with our own experience.

The nitty-gritty and hard lessons yu learn when grinding through a problem yourself will be useful down the line when you encounter a new problem, or they just help you gain a deeper understanding of what yu are working on.

Yes -- this is AI generated Image :D

Want to share some of my past Wow Sandy moments and how I have started missing them.

I can go on with so many examples, but I will try to list a couple of examples in no specific order--

Sudoku solver — I love solving puzzles, and back then Sudoku was still a bit of a novelty. I felt the logic could be coded out to accept any puzzle and churn out an answer. This was back in 2008-ish, and I had just started engineering. We had Turbo C++ as one of our subjects, and I had a decent history of coding and building some functions/simple algos, so it was easy to start with. Shoutout to my brother — because of him, I had access to a laptop and permission to try anything I wanted to.  So yeah, I loved 2-D, 3-D and higher-dimensional arrays, and I used a 4-D array too and made a Sudoku solver.

It was not about optimisation back then, but more about translating my Sudoku-solving method into C++ functions. And back then, yu had to fight hard for simple errors. On top of that, no one was there to guide you through the logic, and I spent hours and hours, and maybe days, but finally got it up and running. My dad had a Nokia mobile, and it had 100 levels, and the code would solve 98 out of 100. That was so satisfying — a big win moment. Like something yu crafted from scratch, troubleshooting each and every aspect, and sometimes waking up in the middle of the night and going back to rewrite the logic, and finally seeing it working.

That grind helped me learn C++ and coding in general much better than if I had relied on other websites to give me a solution. There are so many other examples related to coding — the hobby projects didn't scale to production, but I learnt a lot and spent countless nights developing and debugging. All were worth it. I can't quantify it, but I am sure that kept my logical neural pathways active, and that helped me at work and in life in general.

Then there was this Physics book for tough problems in 11th–12th grade by P.S. Bangui, and God — it still gives me tremors. Each problem took multiple iterations and recalculations. I would never get it right on the first go. Luckily, I had answers at the back to cross-check and professors to help with a few of the problems, but the rest were, again, a hard grind. And each problem gave me a dopamine or euphoric-feeling boost — just that back then I didn't know it was called dopamine or a euphoric feeling. :P

Just imagine not getting the answer and quickly checking online for the solution. In this process, yu don't go through all the options or ways to solve that problem. Yu also don't learn why a certain method works and why that method didn't work for another problem at hand.

Nowadays, this is what we are doing — how to do XYZ? Quickly open any GenAI LLM model and start working with it, and then let it create a blue-background, 10-slide PPT or HTML slide deck. And worst of all, when yu have to present it to someone, yu fumble because AI made up content — yu didn't review it, yu didn't challenge it at all, and took everything at face value.

A better approach could be that yu sit with the thought first and then list down the points. Then have AI for further brainstorming or to help you challenge your assumptions, etc., and then let it spin off some slide deck. Then yu go back again and check if it came out the way you wanted. Otherwise, yu might be better off with a manual PPT — the intention is to convey your thought and not a fancy-looking slide deck.

Remember 20 years back or so — we all remembered so many landline numbers. I can challenge that each of us remembered at least 20 different landline numbers — friends, family, crushes. :P Then later, a few carried that habit forward and started remembering mobile numbers. Although mobile phones had a phone directory, sometimes yu would use a landline to call a mobile and yu remembered the numbers.

Then slowly, mobile calls started becoming cheaper, the phone had its own memory, and yu stopped memorising them, and slowly that part of the brain stopped working or being less active than it used to be. Then, in the last few years, we had OTPs, and we could remember a 6-digit code for a minute or less. But thanks to mobile phones scanning our text messages, it auto-fills the OTP, and yu never even look at it or remember it. Another small brain activity cut off.

I hope you are getting where I am going with this.

Then I have some other good examples from my friends — one of my friends would always do mental maths at the checkout counter in a grocery store. Another friend has gone back to fully manual coding, and it was a good, quick realisation for him — as he wasn't able to write a simple SQL query after Copilot came into the picture. Then my dad — still remembers so many landline and mobile phone numbers. Phew — incredible.

So, in the last year or so, I too got gripped a lot by AI and had so few moments where I got that dopamine rush where I could say — Wow Sandy, you are awesome! Now I wish to go back to it. Maybe not totally, but in a few areas I will take back full control, and in a few cases I will work with AI and figure out ways to preserve my analytical skills.

I really would love to hear your stories and experiences. Where do you go with all this?

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.