My bets for AI and startups in 2026

YEAR OF SMALL LANGUAGE MODELS

The AI infra will pick up a lot of steam and revenue in Small Language Models (SLMs) as compared to LLMs. If LLMs are all knowing omnipotent gods, the SLMs are genie in portable lamps. The requirement of enterprises is task based AI, ie evolving systems with world knowledge of specific topics with low latency and cost. SLMs fits this bill perfectly. Most of the SLM development will be inhouse by ML wizards as the top brass wants higher intelligence embedded into applications that can be relied on. This is why it makes such a strong case for infrastructure play, that too open source. Infrastructure from data annotation, to RL environments, to eval benchmarking and evolving schema. Everything except the models themselves are a great place to build in this niche.

Many startups will realise that building software is easy, but building models is hard. The models require propietary data and architechture of ML models still fundamentally complex. Thus it would be great grounds to compete on. We will see a lot of demand for infrastructure around building these models

multiple better pytorches would be my first 2026 bet.

AI SOCIAL MEDIA (consumer AI)

Every AI startup which has decent traction will start running around circles, desparately wanting a moat - largely to raise money, and if the founders are somewhat decent then to also defend their business long term. The moat thats' being predicted is deep personalisation of AI models, social status being driven using AI content and marketplaces (More on marketplaces later). I want to focus on AI and social status, because there could be some market forming especially after niche adoption of Veo and Sora.

We will start seeing cracks in social media finally. The long lasting bastion of the giants like Facebook, X and others might just show some gap for others to create a space in. (It is also great space for decentralised identity to show value). AI will allow easier engagement with Videos and Content. The below graph is my hypothesis of what an AI social media will look like as compared to facebook.

The reason why I am bullish on AI social media is because it can also help people with "what" to post and not just how to post it. Right now distribution channel do not personalise for an user and suggest what to respond / engage on as it would hated on intially. This makes it a great niche for a startup to build on.

DUMB NICHES

I think 2026 is the year we will see some dumb niches getting a lot of hype and traffic. There is a startup which works on figuring out how you can dream better, and also how you can better visualize, remember and enjoy your dreams. I always found it fascinating as most of my dreams ended post wetting my bed (figuratively and literally as well). Reddit Sub on Dream Interpreation has 93K subs

Another dumb startup I know built a yoga clapping productivity tool, which asks you to do different patterns of clapping yoga to be productive (again personalised to very specific WFH niche) but it got some revenue (perhaps more than 100th iteration of a vibecoding app).

It's harder to predict dumb niches but I am confident there will be many. AI curiosity especially among pro-sumers will be all time high which will lead to dumb niches exploding. Dumb things are easier to distribute as they are talked about more than serious things, so getting a high NPS is less of a challenge for super dumb ideas and super ambitious ideas.

MARKETPLACES

We have already seen glimpses of this when the vibecoding startups in bid the adieu more customers are advertising revenue. When agentic coding is solved problem, but niche community is not, we see rise of software marketplaces. [[This kind of boom and bust cycle was seen in crypto startups which at their base layer is a community of people who will simply not sell their tokens promising a base price for the token.]]

Marketplaces when linked to right demand and supply heuristic, can be trillion dollar economies. The best example for it is obviously content distribution and advertising. To be more particular about kind of marketplaces we will see in 2026, here are my best answers:

• LLM applications (top LLMs - ChatGPT, Gemini, Claude) will come up with ways for external api / data providers to be listed, discovered, reviewed and paid as well and will give rise to LLM app marketplaces. Other LLMs will copy this model.

• Cursor / Replit / Bolt / Lovable … will come up with app marketplaces for applications to be constrained and shared easily (vibecoded) that offer full control to the creators. It will be fueled by funding money to get the ball rolling initially, although the ball will be in the hands of creators more than developers.

I also think that builder x creator will be the most killer combination to posess. If you are an average builder - you should start your creator journey, and vice versa. The biggest oppurtunities will lie in the middle, and keeping up can help you monetize the small wins.

LESS APIGENTIC, MORE MCP

We saw investments in both horizontal and vertical agents in 2025, although personally I think it was too early to invest in horizontal / vertical agents. I would classify agents in three categories:

• chatbots with LLM APIs where distribution is owned by the startup
• chatbots where clients own the distribution, and agents are triggered (ex. MCP, Skills, ChatGPT apps)
• UI enabled interfaces with intelligence delivered by AI

I have been closely following the MCP UI, Registry development. I think clients will evolve in spending less tokens and choosing the right MCPs powered by registry, leading to rise of adoption of MCP / similar architechtures (ChatGPT apps / Claude Skills).

The "vertical" agents lying in first category will still be a hard sell, especially if they are an upteenth vertical agent, with no clear niche to grow out from. This is why less APIGentic agents and more agents with distribution network effects from the LLM Client.

I am also super bullish on interfaces agents. Agents that lie in interfaces, so if an agent is embedded inside an interface, they will see huge momentum, few examples we have seen already:

• Claude Code (Terminal Interface powered by AI)
• Cursor (VS Code powered by AI)
• RogerAI (Mobile Keyboards powered by AI) - (My Startup)

ONE COFFEE LATTE, OMELETTE AND AN AI BUBBLE PLEASE....

A lot of talk has happened about if we are an AI bubble. A lot of people with wads of money have been asked this question and have vehmently denied that we are in one. Bubble is always realised when they pop, till then they are economies. I don't think we are in an AI bubble yet. I think the federal reserve will find itself in predicament where it will lower interest rates to help the unemployment which in turn will lead to a small bubble by the end of 2026. If there was a thing I was least confident about in this list then it would be this (and yet make most money as well) would be the timing of gold rush in AI, but I am confident it will definitely happen by early 2028.

P.S I am building RogerAI

Builder Jounrey -2 FOMO: Fear of Missing Out.

This is one of the words you hear almost always in the startup ecosystem: “Fear of Missing Out.” As a startup founder, I almost always took pride in my ability to envision products and think objectively with clarity, so by no stretch of the imagination did I think I would ever fall for FOMO. When I was founding Kleo Network, I heard this advice over and over: “You need to drive FOMO for investors to invest in your startup.” I used to think, “Whoa, are investors really that dumb?” In reality, I was the one being dumb.

I fell for FOMO—hard. The genesis of FOMO comes from greed. If there is an opportunity to make money, people tend to attach network effects to that opportunity, scale quickly, and create wealth for themselves. Greed isn’t bad. The action paralysis that comes with that greed is.

For the last few months, I’ve been fidgety with my ideas:

→ New idea. New messaging. New GTM.

This keeps repeating. No potential gets realized because nothing is given enough time to compound. Anything great tends to be copied rather than found through one’s own voice and originality. That’s why it’s so easy to copy and so hard to create. It’s not a question of money; it’s a state of mind that’s dictating it.

FOMO affects investors, but it affects startup founders a lot more—especially solo founders. The new thing getting traction is always shinier and more exciting than what you are currently building. That’s why FOCUS and MOMENTUM are extremely hard—and getting them right is the most precious thing.

I want to stick to a specific timeline for my next product, and I will follow this timeline no matter what.

• 8 October — Launch the website

• 9 October — Launch the product

• 10 October — Launch on Product Hunt

Everything needs to be focused on that and nothing else.

Builder Journey - 1

I’m back at square one, and I’m honestly pumped and excited about it. I remember being superbly passionate about an idea and working hard to make it real—and I can feel that same energy now. Why am I doing it?

The answer is to challenge myself. A lot of people, including me, believed that SaaS applications were dead. The reality is very different. SaaS revenues are higher than ever and can be cracked if the right problem, the right product solution, and the right creative messaging are executed well. If you can crack any two, you’ve got a strong, investable business; cracking all three gives you a godlike superpower of going direct to consumers. With AlmondCoder, I feel it hits all three (for now).

What is AlmondCoder?

AlmondCoder is a programming tool similar to Cursor—basically, it helps you “vibecode” your projects easily. It has features I think are crucial as a builder, such as:

• Run Claude Code / Codex / Cursor CLI in parallel, doing different things. No more waiting for one prompt to finish before starting the next.

• Create a Git subtree for each prompt and merge easily using an interactive GUI.

• Get a simple, editable plan for your prompt that shows what changes Claude Code will make and where the prompt will execute. Often, Claude Code struggles to interpret prompts, producing the wrong plan. This helps you correct it before changes are applied.

• Onboarding prompts for open-source projects that let others discover your project architecture quickly; the generic ones help people learn the architecture faster.

• Prompt Pills: for each project, define recurring context “pills” that are appended to your prompts. Pick the pills you need and go.

• Many features (Prompt Pills, onboarding prompts, auto-merging) are adaptive—parts of the software are generated on the fly based on user prompts. This makes the tool effectively “create software on the fly.”

We’ll eventually allow multiple people to collaborate on the prompt and plan and get it approved before Claude does its magic.

Now, the hard part: executing a tool like this is still a bit complex. That includes designing the landing page, getting the messaging right, building the product, and pushing content across social to drive adoption. It’s not easy—especially as a bootstrapped founder (though arguably easier because the hunger to reach revenue is higher). But even in the age of AI, it’s still hard.

I’ll be documenting my journey in a structured way on this blog for future reference. My goal today is to ensure that:

a prompt creates a new Git subtree
conversation history is saved locally on disk using a specific JSON schema
clicking items in the prompt history loads that prompt’s context
I can create a new prompt with the right scaffolding

I’ll share progress in Builder Journey – 2 and how it’s going. Obviously, there are many finer details associated with the above that still need to be addressed.

 

What jobs will AI do?

If we are able to define what kind of tasks AI will be good at then retrospectively we will be able to come up with what tasks AI is not good at. So what is AI good at? AI is most certainly good at coming up with solutions where the outcome of the task is clearly defined, which is why AI is not going to replace researchers. Research at it's very core does not have the outcome clearly stated, thus the process is more important than the outcome, making it very hard to automate. 

A lot of people say coders, marketers, editors will be replaced but I think these will kind of become a single layer of identity, these people's jobs will converge into obtaining a specific outcome by breaking them into smaller chunks of outcomes. it will still take immense creativity (perhaps more, as lot more is being expected from the same person), thus these chunks of outcomes will be largely be done with the help of AI. 

So much hype around AI. So AI enables the creative, the deep thinkers that are excited about the output more than process. AI will become the process, does not mean you do not have to understand it. You still need it but a larger part will be done by large language models. 

The Only Actress I have a crush on

 

Will AI replace Humans - 1

AI is often perceived as a replacement for humans, but in reality, it is far from that. It’s not about the technology itself, but about how it’s perceived. Humans have the ability to practice, build patterns, and improve in a niche over time. AI still does not “learn on the job.” At present, one of the most widespread use cases of AI is software development, yet even here, the tools do not improve at runtime. They require constant orchestration, critical verification, and validation of outputs. These tasks may sound simple but demand deep knowledge and understanding of the systems involved.

Since the Industrial Revolution, people have predicted that human labour would become obsolete. Machines were expected to replace us, and indeed, they made many processes more efficient and production easier. Yet here we are in 2025, and I am using a machine to write this article—human labour is far from gone. The reason is simple: humans adapt, create new economies, and thrive within them. This tradition of evolution is still difficult for AI to replicate.

For example, I would never hire an AI designer in place of a human one. A human designer understands my taste, my product, and can actively learn from and question my choices. LLMs can mimic this to some extent, but the assumption that they truly “get it” is still hard to accept.

This is why I believe AI will go through a Dunning–Kruger–style cycle. Initially, many will overestimate its capabilities and use it as a human replacement. Over time, they will realise these systems are not being challenged in radically creative ways—the kind of challenge only humans can bring. This will increase demand for genuine insight and experienced professionals. The road to such experience may still require years of deep, focused learning, but tools will exist to support that journey. And while we live in a capitalist world, this reality will continue to shape how AI fits into human progress. Although there will be huge productivity jump in systems. I think it would be in order of magniute of cloud jump and not computer jump. So ideally how everything moved to cloud brought in productivity improvement, it was an era when you heard the words like (social local global cloud data science) for the first time. It was also the time when the phrase "data is the new oil" became extremely popular. This phase started in 2005, and followed till 2015. The AI era, which will enable people to orchestrate their jobs with bunch of prompts especially any kind of a soft job, which does sound scary but will eventually lead to new things quickly which weren't possible with AI before in not just software industry but in other industries as well. 

The quote (which I know most people in tech are tired of hearing) of "If I had asked people what they wanted, they would have said faster horses", is so much true today. 

MIVC - Replit + Ruby on Rails for CommandHive

MIVC - Memory, Interface, Verifier, Client -- A MCP Server Design Framework

Memory MCP Servers

An MCP server requires fetching very specific information with the right context. We have already seen multiple memory fetching implementations in order to serve the current context length limitations. Even if context length is increased (Gemini 2.5 Pro), the ability to serve intelligently on vast data decreases. Thus, there seems to be a clear need for intelligent fetching systems for blobs of information. Multiple methods for the same have emerged:

1. LLM Schema Generation + Database Record Creation

In this technique, the information blob is understood and a schema is created. Then with this format, the information is stored in the database. Once the database is populated, the schema is conveyed to the LLM for writing queries on the database to fetch required information.

2. (1.) + Vector Columns

A lot of times LLMs need to understand the relational context for different records. The idea here is not direct inference (SQL) but contextual inference (vectorized words). This requires some columns to be vectorized.

3. Cyclic Knowledge Graphs

This is where LLMs generate knowledge graphs which are connected to each other in a cyclic pattern where edges denote relationships and nodes store specific information.

YADA YADA YADA.

Designing a memory layer should be able to encompass these use cases for information retrieval and any future implementations as well.

Example Code

Example code could look something like this:

fetch_gmail = MemoryClass(desc="fetch gmail email information via Vector Columns")
res = fetch_gmail.lookup(summary="flight tickets from india to new york")

The MemoryClass itself would look like:

# Schema
Id = email id 
Subject = string 
Summary = Vector DB 

def lookup(input):
    return model.summary.find(input)

This could also be cyclic knowledge graphs or Retrieval Augmented code.

Now one could load a compatible Vector Database from it like Pinecone, Milvus, or MongoDB. More thought needs to be put into how the actual code would look like. I'm happy to take feedback on the same. Right now this is akin to how models work in MVC architecture in Ruby on Rails.

Interface MCP Servers

Often these LLMs are required to act upon specific interfaces - e.g., Browsers, Software, Blender, Linux Terminals, Operating Systems. There are a limited number of interfaces where these LLMs can interact. The idea is to load an interface akin to a 'ruby gem'. The developer of these interfaces can constrain and define how the LLM talks to these interfaces. For example, in case of a browser, a DOM can be served as input, whereas output can be executed on the Browser console. In the case of software, the input can be different menus/clicks on the software and the output will be a screenshot of the software window after different actions.

Interface Components

Each interface will have three main components:

1. Service Command - This is similar to MCP servers' commands with arguments. The difference is it points to terminal opening command, starting of docker command, running an operating system VM...

2. Input Interface Experience - The inputs to these interfaces will be required to be constrained by the LLM. This will be based on the choice of interface developer.

3. Output Interface Experience - The output design from the interface requires LLM communication. This again will be based on the choice of interface developer.

Unique Features of Interfaces

• Each interface will be an MCP server in itself
• Each interface can be loaded within another MCP server, to serve as a base layer to be built further

Example Interface Code

An example code can look like this for defining an interface:

Interface ABC

Service Commands:

@command
def start():
    args = ["commands"] / "start.sh"

@command
def stop():
    args = ["commands"] / "stop.sh"

Input Interface:

# take input as screenshot 
screenshot.validate(type: image) 
definition: "this image describes the state of the software, try to understand if the user is clicking something and how this image is different from base software..."

Output Interface:

# take output as actions on a software 
mouse.click(x: 123, y: 122)
keyboard.input("top players")
dom.execute("$('.find').click()")

More thought needs to be put into how the actual code would look like. I'm happy to take feedback on the same.

Verifier MCP Servers

The responses from the LLM need to be verified by a separate black box whose context is not visible to the LLM.

For example, the verifiers can be used to understand the LLM response, if it:

A. Serves the purpose or not. If the response further requires a deeper LLM probe or multiple subagents to complete the task.

B. Should be served to the individual asking it (based on role of the individual or personalization of the individual). If there is further personalization that can be done to the response.

Another example can be if the input is correct and needs to be further detailed or explained before giving it to the main interface/further passed on.

Verifier Features

These are basically a black box unit serving as an LLM which runs when the developer wants to. It can be:

• Just after the LLM input
• After the LLM response
• During the interface communication

They can access the memory for personalization, fetching roles. They can modify the LLM response. We also want this to serve as an integral layer to integrate with other eval services for agents that exist such as TensorZero, LangChain evals. The idea, although, is that eval intelligence should be a black box to the definition of the agent.

Verifier Code Example

# response/input = as defined previously in code 
bool_access, sanitized_response = Verifier.verify(
    "this is meant for a HR professional in an organisation, check if they should have access to this answer/tool call"
)

if bool_access:
    return response
else: 
    return sanitized_response

Client

This can be a pub/sub Kafka on a socket, it can be terminal commands, it can be a chat interface. The idea here is to make the current IO for MCP servers more flexible to serve different clients. The client can be customized to have authentication, social OAuth, yada yada again loaded into the server with packages/gems/libraries which can act as proxy. The idea here is to build composable client units for main IO. Right now what's defined by Python decorators actually needs to be a lot more flexible serving more use cases. The idea here is to not restrict the intelligence by a single "chat client" design but allow more feature-rich clients to exist.

Example Agent Flow

Here is what an example flow and code for an agent may look like. This is an agent which checks my email address for specific flights, finds my passport information from a personal database and applies to VISA for a country I am travelling to:

# Initialize components
email_memory = MemoryClass(desc="Gmail flight information via Vector DB") # defined in Memory folder
personal_vault = MemoryClass(desc="Personal documents storage") # defined in Memory folder 
browser_interface = Interface("BrowserAutomation") # Similar to Importing a gem 
visa_verifier = Verifier("travel_document_validator") # defined in travel_document_validator.py
country_verifier = Verifier("country_verifier") # Verify LLM response 

# Agent workflow
def travel_visa_agent():
    # 1. Fetch flight information
    flights = email_memory.lookup("recent flight tickets")
    destination_country = email_memory.lookup(flights + " countries as an Indian I need visa to and can be given online")

    # 2. Verify the destination country obtained is correct from the email. 
    can_proceed, destination_country = country_verifier.verify("check if it is valid country, just return the country name, indian citizens require a visa and visa can be obtained online")
    if !can_proceed:
        return

    # 3. Retrieve passport details
    passport_info = personal_vault.lookup("passport document current")

    # 4. Verify eligibility
    can_proceed, sanitized_data = visa_verifier.verify(
        f"visa application for {destination_country}", 
        context={"flights": flights, "passport": passport_info}
    )

    if !can_proceed:
        return

    # 5. Interface with visa portal
    browser_interface.start()
    browser_interface.navigate("visa-portal.gov")
    browser_interface.fill_form(passport_info, flights)
    browser_interface.submit()

    return "Visa application submitted successfully"