LLMs can explain almost anything. They’re astonishing at recall — chess openings, loan rules, tax codes, you name it. But ask them to play the game rather than describe it, and they fall apart.

In the recent Kaggle chess tournament, top models collapsed within a few moves: forgetting state, making illegal plays, losing track of strategy. They had knowledge, not understanding.

Back in 2016–2019, when I was investing in AI startups, the dream was autonomy. But the closest we got were brittle smart home routines and Alexa Skills. Today LLMs can finally act — reason to call APIs, run tools, and orchestrate workflows.

And yet, reasoning-based autonomy isn’t intelligence. Intelligence requires something LLMs still don’t have: persistent memory and a model of cause and effect (a world model).

Without those, every prompt becomes a fresh reset. This is why so many “AI agents” behave like flexible RPA bots — they follow instructions beautifully, but they don’t recognize when those instructions no longer make sense.

What could make an agent reliable?

The same thing evolution gave us long before higher cognition: a lizard brain — fast, strict, rule-bound sanity checks. In software, that layer is the compiler.

Compilers Are the Missing Layer of Reasoning

AlphaGo didn’t win because of a neural network alone. It won because the network lived inside a strict rules engine that validated every move. AlphaFold and AlphaEvolve breakthroughs aren’t magic intuition; they are the product of a model wrapped in domain-specific structure and verification.

A compiler does one thing exceptionally well: enforce domain rules before an action executes. Not unlike the limbic system, it doesn’t think, but it prevents catastrophic mistakes instantly.

LLMs generate ideas. Compilers make those ideas safe, consistent, and grounded in constraints.

This is the layer that turns a model from autocomplete into something that behaves like a system.

Why Compilers Are Becoming the New Moat

The companies that figure out the right compiler for their domain will own the deepest moat of this AI cycle. Compilers are where domain logic lives, and domain logic is hard to copy.

You can ask another LLM to serve as a verifier (the trendy “self-healing loop” in coding agents), but anyone who has vibe-coded knows what happens: you get faster iterations of the same mistake.

Human-defined policy layers are even stronger. One reason platforms like Mercor grew so fast is that businesses want expert policies for reinforcement learning that act as constraints, not suggestions. The more critical the task, the more valuable those constraints become.

Compilers are becoming the new quality layer, the new safety layer, and ultimately the new competitive advantage layer.

Where This Gets Exciting: Scientific Reasoning

Compiler-first approaches are quietly reshaping scientific reasoning, where correctness matters more than fluency.

• AI Feynman (MIT) explored physics by navigating constrained mathematical structures.
• Harmonic AI translates problems into Lean 4, a formal theorem prover — a compiler for mathematics itself.

These systems don’t just “chat about” physics or proofs — they can check whether a solution is actually true.

And now, newer neuro-symbolic systems — such as AUI’s recent work — push this further by mixing learned representations with fully verifiable logic. They bring formal reasoning to business domains that previously relied on heuristics and human oversight.

This is where AI starts doing more than generating text: it starts producing reasoning we can trust.

Founder’s Take

At Gauss, we realized something simple: building the agent was easy, engineering the compiler was the moat.

Our debt management engine works because every action — every credit report analysis, every refinancing route — is checked in real time against user constraints, financial benefit, and regulatory rules.

The LLM handles the conversation. The compiler ensures the outcome makes sense.

The same pattern holds for QA. Our testing stack combines autonomous LLM tests with strict logic in Maestro. The compiler layer keeps reasoning consistent across updates. Without it, the entire system would drift within days.

Every durable AI product is secretly a compiler product.

LLMs today are stunning at language but still weak at reliable reasoning. True reasoning requires memory, stable world models, and constraint-aware planning.

All three remain open research problems. Which means the practical path to useful AI agents is hybrid: LLMs + strong compilers.

Model weights won’t be the moat eventually. Fine-tuning won’t be the moat. Defensibility still sits in the rules, constraints, and verification layers wrapped around the model.

The Bottom Line

If 2019 was about autonomy, 2026 is about reasoning with persistent memory.

And until we solve reasoning at the model level, compilers are the only reliable bridge between “AI that sounds smart” and “AI that makes correct decisions.”

The winners in the next wave won’t be the companies just deploying LLMs on proprietary data. They’ll be the ones building the lizard brains that keep those models grounded in rules, reality, and accountability.

The real moat forms at the intersection of reasoning, constraint, and execution.

Compilers: The Lizard Brain Missing From LLMs was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Trouble

COVID has teleported the restaurant industry to the cross-roads it was slowly getting to over the last 5–10 years. The industry is having its Amazon moment right now, and it’s up to restaurants to recognize that and decide their fate — be completely commoditized and pressured out of the business or take control of the relationships with diners back from digital marketplaces and find a way to serve diners on terms that work for restaurants.

Big food delivery marketplaces are playing the Amazon game for a while now. They brought convenience and low prices to diners at the expense of restaurants’ and their own profitability, hoping one day to get to scale where economics can be changed in their favor with a click of a button. To get there, marketplaces had to put diners at the center and control the relationships with them at all costs — not unlike in Amazon case, it’s the consumer who dictates their rise and fall.

And that’s a total disaster for restaurants. The promise of incremental sales, that sounded so appealing 5–10 years ago, turned out to be a way to loose brand identity in front of a digital consumer and to pay for that loss with a significant fraction of revenue and sometimes more than 100% of profits.

For majority of restaurants, being on a marketplace means being a square box with a name in a long list of almost identical options for a diner, who priorities delivery time and prices. Few have a luxury of a strong offline brand or a marketing budget to stand out. And building a digital brand from scratch on a marketplace restaurant have no influence over is nearly impossible.

This is still relatively early days of trouble, there’s still revenue flowing in, and though it’s unfair in a sense that it’s often not incremental or profitable, it still helps to pay the bills. But not for much longer. With delivery quickly growing in scale, even more so due to COVID, and marketplaces losing money on every order, they will have to find a way to turn their business around sooner than later.

There’s a few ways they can try to do that — running more of their own virtual brands out of dark kitchens, directly competing with their restaurant partners, or raising the prices for restaurants and diners. Given how sensitive the diners are to pricing after being lured for years with coupons and promotions and how important their growing engagement is for marketplaces to survive, it looks more likely that the major part of the the increased fee burden will fall on the restaurants again, and only the strongest brands and largest operations will be able to survive.

We know that Amazon succeed in this model a while ago. We know about the miserable fate of Amazon suppliers, commoditized and competing fiercely for a few percentage points of profits with other suppliers and Amazon own brands. In the world of e-commerce, a business of selling commodities at a large scale, it can still make sense.

But I can’t imagine how restaurant business can be done this way. I think the industry is shooting itself in the foot every day it keeps working through existing marketplaces and I think it’s only a few years way from being forced to quickly loose its hospitality roots. COVID has accelerated this process dramatically by making digital channels overwhelmingly important.

The Solution

Diners preferences for omni-channel convenience are not going away any time soon, so there’s probably no going back from marketplace aggregation model. Restaurants have to find a way to meet diners needs and prevent commoditization at the same time.

I salute the attempts to establish direct connections with diners and promote their own delivery and pickup services, that hundreds of restaurants all over the country are trying to do today. I salute initiatives like Tock 20 that try to reinvent fee structures and data ownership rights for restaurants.

But I’m afraid those efforts are just not enough anymore, because diners will keep requesting convenience of choice and lower prices, and marketplaces will keep providing it at a huge scale, incomparable to capabilities of any given restaurant brand, even if it’s McDonalds.

What restaurants really need is a new marketplace, that serves diners at least as good as the existing ones, but also puts restaurants in the center. The economics of such a marketplace would prioritize restaurants, having diners preferences as requirements and keeping little to its own benefit. The only way to incentives a model like that is to build one.

I call for all restaurants to collectively form a new co-op-like marketplace, that would be serving diners and restaurants more than itself and would facilitate and nourish direct diner-restaurant relationships, building digital brands for restaurants and keeping diners happy with the prices and service.

It’s not impossible — it’s just a matter of taking a stand. And it’s now or never for the industry to do that.

Restaurants Beware: Amazon Moment Ahead was originally published in Rehunch on Medium, where people are continuing the conversation by highlighting and responding to this story.

Integrate forecasting into your development flow with CircleCI

About a year ago I was trying to figure out how to get fbprophet forecasting work on a AWS Lambda and eventually got it working. Since then the need for serverless forecasting matured, and more people got interested in making the tech seamless, leading to some very helpful stuff, like an fbprophet assembler for AWS Lambda by Marc Metz.

A natural evolution from just getting the package working is to make it part of your CI/CD process. I had a need to deploy my forecasting code frequently — was integrating a forecasting microservice into other apps — and manually generating and uploading zips was not an option. I’m gonna share how I solved it for CircleCI. Hope you’ll find it useful and reusable for other CI/CD solutions.

The foundation for consistent deploys is this Docker image with fbprophet pre-installed into AWS Lambda Python 3.6 environment. It has full, unedited fbprophet, so that customization is possible on the CI/CD side. For example, you may or may not want to uninstall matplotlib from the Docker.

Feel free to use he image at your discretion. Below is the Dockerfile for it (built off Marc Metz’s) and here’s the whole repo.

# Dockerfile

FROM lambci/lambda:build-python3.6

ENV VIRTUAL_ENV=venv
ENV PATH $VIRTUAL_ENV/bin:$PATH

RUN python3 -m venv $VIRTUAL_ENV
RUN . $VIRTUAL_ENV/bin/activate

COPY requirements.txt .
RUN pip install — upgrade pip
RUN pip install -r requirements.txt

# requirements.txt
pystan==2.18
fbprophet

Below is the CircleCI config.yml code I use. It leverages the path to the virtualenv set up in Docker to prepare fbprophet for deploy.

# config.yml

# assumes the repo structure like this:
# repo_name
#   main_repo_folder
#      ...
#   name_of_lambda_handler.py
#   requirements.txt

version: 2
jobs:
  build:
    docker:
      - image: amacenov/aws-lambda-fbprophet
        environment:
          AWS_ACCESS_KEY_ID: 'xxx'
          AWS_SECRET_ACCESS_KEY: 'xxx'
          AWS_DEFAULT_REGION: 'xxx'

    steps:
      - checkout

      - restore_cache:
          keys:
            - v1-dependencies- #{{ checksum "requirements.txt" }}

      - run:
          name: install dependencies
          command: |
            VIRTUAL_ENV=/var/task/$VIRTUAL_ENV  # path was set up in the Docker image
            source $VIRTUAL_ENV/bin/activate
            pip install -r requirements.txt

      - run:
          name: make prophet small enough for lambda
          command: |
            VIRTUAL_ENV=/var/task/$VIRTUAL_ENV
            source $VIRTUAL_ENV/bin/activate
            pip uninstall -y matplotlib
            find "$VIRTUAL_ENV/lib/python3.6/site-packages" -name "test" | xargs rm -rf
            find "$VIRTUAL_ENV/lib/python3.6/site-packages" -name "tests" | xargs rm -rf
            rm -rf "$VIRTUAL_ENV/lib/python3.6/site-packages/pystan/stan/src"
            rm -rf "$VIRTUAL_ENV/lib/python3.6/site-packages/pystan/stan/lib/stan_math/lib"

      - run:
          name: prepare zip
          command: |
            VIRTUAL_ENV=/var/task/$VIRTUAL_ENV
            pushd $VIRTUAL_ENV/lib/python3.6/site-packages/
            zip -9qr ~/repo/name_of_the_zip.zip *
            popd
            zip -9r name_of_the_zip.zip main_repo_folder/
            zip -9 name_of_the_zip.zip name_of_lambda_handler.py

- save_cache:
          paths:
            - ./cache
          key: v1-dependencies- #{{ checksum "requirements.txt" }}

      - run:
          name: push to s3
          command: aws s3 cp name_of_the_zip.zip s3://your_s3_bucket_name/name_of_the_zip.zip

      - run:
          name: push function code
          command: >
            aws lambda update-function-code --function-name your_aws_lambda_function_arn
            --s3-bucket your_s3_bucket_name
            --s3-key name_of_the_zip.zip


workflows:
  version: 2
  deploy:
    jobs:
      - build:
          filters:
            branches:
              only: [master]

Next time will share a bit more about how I use fbprohet at scale.

Cheers!

CI/CD fbprophet on AWS Lambda using CircleCI was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who’s Really Making Money in Food Delivery?

Just recently PitchBook reported a new $600M round for DoorDash at $12.6B valuation. And Amazon put $575M into DeliveryHero. Venture capitalists predict cloud kitchens will take over restaurants. Investors and early employees of delivery companies open up interesting public discussions on the future of the industry. And pundits are concerned our society will become even more atomized. So much attention to a relatively old service — getting prepared food to your door. What is actually going on? And who benefits most from all this hype? Let’s take a closer look at the industry to better understand its dynamics and to see where it’s all headed.

There’s a few key stakeholders in the game: delivery companies, their investors, their employees, their customers and their restaurant partners. We’ll talk about all of them and pay a closer attention to the last group — restaurants — that are affected by the phenomena in a few non-trivial ways.

Delivery companies (marketplaces) like DoorDash are mostly business model and not technology innovations. They rely on a set of existing platforms, from cloud computing to GPS and mobile phones, and, as it often happens with business model innovations, disrupt business models of other players.

The business innovation ideas revolve around creative ways to subsidize scaling efficiently. Efficient scaling is also the basis for fierce competition and rapid market share moves when one of the companies figures out a better way to do it. Venture capital is the major source of scaling subsidies, but also treating delivery employees as contractors and charging both consumers and restaurants for a match. This is essentially the Uber model, applied to an adjacent vertical. It’s no coincidence Uber Eats is the major extension of the main Uber product.

How is venture capital paid back for the subsidies? Scale delivers billion dollar valuations and hundreds of millions of dollars in revenues. That opens doors to IPOs. Retail and professional investors buy out venture capital investors at a hefty premiums under a promise of further scale and valuation growth and even profitability (maybe). Amazon pioneered this model in early 2000s and it’s been working ever since for the ever-growing list of venture-backed unicorns.

How are delivery employees compensated? They aren’t, really. People get some income source, but they agree to a hard job with an underpayment compared to traditional jobs that have social security, pension and other benefits and protections. This agreement often comes from having very limited employment options.

What about consumers? Seems almost like a fair deal here. On one hand, it’s expensive — you have to pay the restaurant price, the delivery fee, and some tips to make it a bit more fair for the delivery guys. And you don’t get the full service from a restaurant you’ve paid to, and you miss on the social experience of dining out, and you risk getting the food in a not very consumable shape, because restaurants still have a hard time adjusting their menus to delivery conditions. But all that balances out if you believe you have better/more valuable things to do with your time while waiting for the delivery. And that’s apparently the case for more than 50 million Americans these days.

Finally, where do restaurants stand? This one is tricky. The promise of delivery marketplaces to the restaurants is very clear — get more customers and more revenues at no extra fixed cost. But the profitability of this new revenue streams is extremely opaque for the restaurants.

The scale of delivery marketplaces is the key here too: their huge operations and the need to at least break-even on an average delivery (which is hard to do on small checks) dictate high revenue share fees — up to 30% and sometimes even more. Marketplaces don’t know and, frankly, wouldn’t care how their fee structure affects restaurant profits.

Unfortunately, neither do most of the restaurants. Most of the delivery platforms claim that restaurants do not fully understand the concept of variable costs and that contribution margins after fees on their platforms are positive. But except for the largest chains, that have data infrastructure and data science teams to figure out contribution margins down to every menu position in every location, the rest of the restaurant industry is having another “Groupon Moment” - “Everybody’s doing it, my top line is growing, and that’s all that matters”. More often than not, as Groupon days clearly showed it before, earning a proportional extra profit from this growth is very hard.

Moreover, restaurants have no access to their delivery customers. Customer relationships and data are fully owned by delivery marketplaces. Restaurants have to compete blindly, passing their destiny on the platforms to algorithms that maximize revenues and fees for the marketplaces and, sometimes, for the their largest partners like McDonalds. The problem of misaligned incentives may become really big, as we all know well from the examples of Amazon and their suppliers or iTunes and the music labels.

Surely, restaurants can benefit from delivery revenue streams. They just have to properly address a bunch of complex business questions about their own operations, as well as delivery channels and their customer flows. For example, “What are the contribution margins of my menu items?”, “What are those margins after delivery fees?”, “What about margins from the brunch menu vs. dinner menu?”, “Are we cannibalizing high margin sales when people dine-in less often?”, “How are customer preferences on GrubHub different from Uber Eats?” With proper analytical tools available only to larger chains, it’s fair to assume that the gross delivery benefit of the restaurant industry as a whole is limited, if not neutral.

Restaurants can try to offload the burden to landlords by trying the new cloud kitchen model. No dine-in service means cheaper rent, less labor costs, no cannibilization, very limited waste and fraud, and stable menus optimized for delivery. But the new cost structure has almost the same net margins as the traditional one, because now delivery fees apply to all of your customers, not just a smaller portion of them. The true benefit is the ability to scale your operations much more easily, so that the dollar value of profits has a much higher potential. At the same time, the big caveat of the model is that a restaurant is not in full control of its destiny, when delivery platforms have both so much power over the business and misaligned incentives.

Another trick for the restaurants would be to build their own delivery operations. But that has its own obvious tradeoffs — doings things that are not in the core competence and are very hard to scale to meaningful ROI. A few players will be able to pull it off, sometimes merging it with the cloud kitchen model, but the approach doesn’t sound like a generic solution.

So this it then, we are looking at the same zero sum game — venture capitalists as a group make a lot of money by fueling companies that cater to the population obsessed with convenience. A few hundreds of people (founders and early employees of delivery companies) get rich along the way, hundreds of thousands get some additional cash to pay the bills. The rest of us are mostly paying for it and enjoying (hopefully) our growing productivity and/or leisure time.

Here at Agnoris we try to improve the business outcomes for the restaurants. Hopefully others will step in and help find better solutions for delivery employees and consumers, so that the zero sum game transforms to a growing the pie game.

I assume you’re reading this post because you’re looking for ways to use the awesome fbprophet (Facebook open source forecasting) library on AWS Lambda and you’re already familiar with the various issues around getting it done. I will be using a python 3.6 example, but the approach is applicable to other runtimes as well as other large ML libraries. Without further ado:

1. Install Docker locally. An alternative is to run a EC2 instance and copy files between the instance and local machine, which feels more complicated and less reliable to me.
2. Run a shell on a relevant Lambda image (take a look at lambci) from the working directory with your code, that is supposed to run on Lambda (which has the lambda handler):

docker run --rm -it -v “$PWD”:/var/task lambci/lambda:build-python3.6 bash

For an explanation of the commands used here go to Docker docs or here.

3. Create a virtual environment and install relevant packages:

python3 -m venv venv
. venv/bin/activate
pip install --upgrade pip
pip install fbprophet --no-cache

4. You can check if your code is working: python lambda_handler.py

5. Reduce the venv size to be below the 250Mb limit:

pip uninstall -y matplolib

find "$VIRTUAL_ENV/lib/python3.6/site-packages" -name "test" | xargs rm -rf

find "$VIRTUAL_ENV/lib/python3.6/site-packages" -name "tests" | xargs rm -rf

rm -rf "$VIRTUAL_ENV/lib/python3.6/site-packages/pystan/stan/src"

rm -rf "$VIRTUAL_ENV/lib/python3.6/site-packages/pystan/stan/lib/stan_math/lib"

echo "venv size $(du -sh $VIRTUAL_ENV | cut -f1)"

What happens here is that you’re getting rid of matplotlib (if you don’t need plotting), tests, and the pystan source codes (the heaviest part of the package). Last command displays the size of the venv, which should be below 250Mb.

6. Make sure your code is still working after the cleanup: python lambda_handler.py

7. Create a .zip to upload to Lambda:

pushd $VIRTUAL_ENV/lib/python3.6/site-packages/

zip -r -9 -q /var/task/name_of_your_zip.zip *

popd

zip -9r name_of_your_zip.zip name_of_your_code_folder/

zip -9 name_of_your_zip.zip lambda_handler.py

8. You now have a .zip in your working directory that you can use for Lambda. You can stop/quit Docker now — the zip will still be in your folder.

Additional resources:

Great post on preparing ML libraries for Lambda: https://medium.com/@maebert/machine-learning-on-aws-lambda-5dc57127aee1

The discussion on preparing fbprophet for Lambda: https://gist.github.com/CarstVaartjes/77dbe8249d171e592bd17847f7009272

Reducing the size of scipy: https://gist.github.com/wrwrwr/4a38a17113e3845f3385e9388effc064

How to get fbprophet working on AWS Lambda was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recent F8 conference, where FB introduced new features of its Messenger platform in an attempt to re-ignite “rocky roll-out” and slow adoption, triggered my thinking about what would make bots more successful.

If you look at top-5 bots on Product Hunt, 4 out of 5 will be platforms for building bots. The hype around bots, that started in 2016 with FB introducing bot-building API for Messenger, hasn’t materialized until now.

I see a few reasons for that.

First, the hype around natural language understanding (NLU) in voice/text interfaces as a substitute or universally better version of visual interfaces is misleading, see for example this great post by Benedict Evans with analysis of voice interfaces. It is simply not the case that texting or talking is universally more convenient than seeing and clicking. Think of any use case where you have to deal reach a decision through by analyzing multiple options, parameters and steps, for example finding the cheapest flight in the next 3 months, and what type of UI would be more convenient for you personally. Bandwidth of our vision is order of magnitude higher than of our typing, reading or hearing (see Moran Cerf’s data from recent Tim Urban’s post).

Second, platform owners, be it Facebook with Messenger or Amazon with Alexa, intentionally or not, positioned bots to developers as a great AI vehicle. This positioning formed expectations of both developers and users that bots are sophisticated agents, capable of complex reasoning. Such perception was naturally driven by expectation of NLU capabilities of bots that are inherent for messengers and voice platforms. But it turned out that human level NLU in chatting contexts is extremely hard do develop, despite all great tools made available to developers, such as Wit.ai or Api.ai. It’s even harder to enable bots with true reasoning capabilities, that would account for quickly changing intents in real life conversations. In many options- and reasoning-heavy cases, when bots promise to be natural and convenient way to transact with businesses, they turned out to be impractical (see Kayak Messenger bot screenshot below).

Moreover, in most of these cases user experience with bots is inferior to apps, where UI is manly in charge of clean visual representation of options, and is not scenario-dependent. Apps maybe a few extra clicks away from user’s current active flow, but it’s still worth switching to make an educated decision faster.

No doubts bots can work well in many complex cases, but development of a compelling bot is very hard. See, for example, Seth Rosenberg’s post, revealing how much effort the first KLM bot required from the Messenger team. Anyone who tried to develop a bot with NLU elements knows, that even the most basic conversations require developing processing logic for a vast number of possible scenarios and that even then a very large chunk of real life user behavior will remain uncovered by bot’s logic. This is so much different from apps development, where a developer doesn’t have to think through all possible permutations of user’s actions. Facebook et al. democratized bot creation a great deal and users saw a flood of bots, but majority of bots remain low quality products (that deservedly don’t see traction) due to hardness of bot’s logic development.

Lastly, even for good bots their utilities will most probably be quite limited, leaving a lot of functionality to traditional apps. This is why better bots, for example Epytome Stylist on Messenger, are very transparent about bot’s functionality up front and leverage all possible platform tools to mix NLU with traditional visual interfaces.

Despite limitations and unimpressive start, I believe bots as a new UI platform has great potential for boosting revenue and efficiency of various businesses if leveraged in certain use cases. I’m thinking of 2 broad categories.

The first category is more consumer-oriented and relates to cases when a bot automates relatively simple actions that currently require users to do multiple app switches and clicks. I’m essentially talking about aggregation and streamlining of well-defined scenarios (“save me clicks”). Imaging you’re looking for a fastest/cheapest way to get from point A to point B. Your current routine could include looking at possible routes, traffic jams and travel time estimates in Google Maps/Waze/Moovit apps, than switching to Uber and/or Lyft to check for ETAs and prices and maybe even checking Zip Car availability or Weather app to make a decision on how to commute best. Worst part — you’re doing the same routine almost every time you need to commute. A single-function bot, provided with location information, could make this task much easier for your by just presenting you top-3 options (cheapest, fastest, most convenient) and executing your choice in “no questions asked” fashion. The first KLM bot, built in collaboration between KLM and Messenger teams, falls into this category.

If you’re working on a use case like that — ping me, maybe we could invest in your company. :)

The second category is more business-oriented. It is about automation of repetitive and relatively basic interactions between customers and businesses (if they are not automated already)— bookings, payments, FAQ answers retrieval etc. Aggregation may add additional value to consumers here, when a bot is also a UI aggregator across various providers (for example, buying movies tickets for any theater in town), but it is not a must. Many of current success stories of enterprise bots fall into this category with customer service functionality.

An important edge case in this category is when a bot is just a substitute for typing in a Google search request or an URL or simply looking at the home screen of an app.

In this case conversing with bots doesn’t add much value over common visual interfaces. Take for example hyped fintech bots for so called conversational banking, when you can ask bot for account balance. Your banking app is probably a much more convenient way to quickly get a snapshot of your finances and to make transactions — simply way less clicking!

An argument in favor of this edge case is that a bot can keep your current conversational context uninterrupted and save you the app switching effort. This was probably the rational behind extensions — an option to access some service providers functionality from your current conversation, that Facebook has just added to Messenger, following the move by iMessage.

In many cases, e.g. OpenTable, extensions just open web pages from service’s web site in the Messenger shell.

Extensions are much less about conversational bots and NLU and much more about bringing traditional UI to your conversations seamlessly. In some cases the idea of inviting a third party to your conversation to do something may feel quite weird because that would interrupt the conversation flow. And sometimes, when it’s about content sharing or making a collective decision, e.g. sharing a song or ordering a take away for the team, it may feel natural and convenient.

Extensions can “save clicks” and be natural part of conversations. They can help Messenger become a more powerful ecosystem similar to WeChat. But one of the major bot challenges remains true for extensions — creating seamless mechanism for discovering a relevant bots is hard. Time will show if the “bot store” offered by Facebook solves the challenge. I’d personally love to see the evolution of the store from just a pop-up tab to a seamless in-conversation search engine, similar to the mentioning mechanism of messengers, e.g. add Spotify bot to a conversation by typing “@Spotify” or, more broadly, “@Music” for a default bot in the category.

As much as I’d love to see more progress in general AI and digital reasoning, it seems more likely that AI will keep developing in “verticals” — not just business verticals, but also tech verticals like object recognition in videos. This means that for bots/extensions to see real user adoption developers will need to 0) carefully think about bot value add vs. traditional channels 1) manage users’ expectations by being upfront and explicit about bot’s purpose, functionality and limitations 2) keep NLU functionality under tight control and 3) in many cases incorporate human handoff to bot flows. I see these conditions essential for building trust and true scaling.

Would love to hear your thoughts on the future of bots for messengers!

What defines bot success on messaging platforms? was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.