We spent a decade convincing enterprises to stop trusting the network. Now we’re handing production access to a new kind of user that breaks the assumptions we built that trust model on — and most security teams haven’t noticed yet.

The thing zero trust actually replaced

For years, enterprise security ran on the castle-and-moat model. Authenticate once at the VPN, and once you were inside the network, you were trusted to reach almost everything. The perimeter was the trust boundary. The problem only became obvious after it failed often enough: one breached laptop or one stolen VPN credential, and the attacker was inside the trusted zone, free to move laterally to anything the network could see.

Zero trust threw out network location as a signal. The slogan — “never trust, always verify” — gets quoted to death, but the substance is five principles:

No implicit trust from location. Sitting on the corporate network earns you nothing. Every request is treated as if it came from the open internet.

Verify per request, not per session. Trust isn’t a gate you pass once at login. Every access to every resource is re-evaluated.

Least privilege, just-in-time. You get the minimum access needed, for the narrowest scope, ideally only when you need it — not a standing grant that outlives its purpose.

Dynamic, context-aware policy. The decision uses live signals: identity and MFA, device posture (is the laptop patched, encrypted, managed?), location, time, a behavioral risk score. The same person is waved through from a managed laptop and challenged from an unknown one.

Assume breach. Design as though the attacker is already inside. Segment the network so a compromise stays contained, encrypt everything, log every request so you can trace it.

The part that matters most is the architecture underneath. Zero trust is enforced by a split between a Policy Enforcement Point and a Policy Decision Point. The enforcement point sits directly in the data path — every request physically passes through it. For each request it asks the decision point a single question: given this identity, this device, this resource, this context — allow? It lets the request through only on a yes. The enforcement point is the choke point; the decision point is the brain. Conditional Access in Entra and Okta’s policy engine are decision points you’ve probably used today without thinking about it.

Hold onto that picture, because it’s about to get a new kind of user.

Now the user is an AI agent

Here’s the shift almost no one has internalized: an AI agent’s tool call is the new access request, and the gateway it calls through is the new enforcement point.

The good news is that most of zero trust ports over cleanly. An agent needs a strong, verifiable identity — none of this “a service account called the API” blur where no one can tell which agent, which owner, or which user was behind an action. Per-request verification becomes a gate that re-checks every single tool call, fresh, instead of trusting a one-time provisioning event. Least privilege becomes default-deny tool access. Assume-breach becomes containing blast radius per credential.

So far, so familiar. The trouble is that an AI agent quietly breaks four assumptions the human model leans on — and those four breaks are the entire reason agent security is a new problem and not a config change.

1. Identity is compound, not singular

A human is one principal. An agent acts with two identities at once: its own, and the human whose authority it’s borrowing. Human zero trust verifies one subject. Agent zero trust has to verify the pair — who is the agent, and whose permissions is it actually using right now — and re-establish that at every hop when one agent hands off to another. Carry the entry-point authorization blindly through the chain and permissions accumulate: the sum of what a workflow can do ends up exceeding what any single principal was ever authorized for. OAuth’s on-behalf-of patterns were never designed for recursive, multi-agent delegation.

2. The unit of risk is an autonomous, prompt-driven state change

A human clicking “open file” has bounded, self-evident intent. An agent’s call is non-deterministic — driven by a prompt — and chainable. It can read from your CRM and then email those contacts. Human zero trust almost never has to evaluate “intent,” because the human is the intent. For agents, intent is the whole game. Each action can be individually permitted while the sequence is exactly what you’d never allow. “What can this identity do?” stops being a sufficient question. You have to govern what it’s doing, in context, as it does it.

3. There’s no device, and the request rate is machine-speed

Human zero trust leans hard on device posture — is this a managed, patched, encrypted laptop? An agent has no laptop. The posture-equivalents are different signals entirely: which credential is being used, what scope the token carries, whether the call came from a live human interaction or a background routine, and where the prompt came from. And where a person makes a handful of access decisions a day, an agent makes thousands of tool calls. The gate has to be cheap and fresh enough to run on every one of them, not sampled, not cached into irrelevance.

4. “Just-in-time” has to become “just-for-scope”

Humans trigger access reviews when they change roles. Standing grants get re-certified. Agents have no equivalent lifecycle — they accumulate scope incrementally, each expansion feeling reasonable, with no natural moment that forces a review. Scope creep isn’t an edge case for agents; it’s the default outcome. The fix adapts the least-privilege principle: instead of provisioning access and deprovisioning it later, you issue a short-lived token scoped to this capability for this conversation, and it simply expires. No standing grant to forget about. No deprovisioning job to fail silently.

The reframing

If you want one sentence to carry the whole idea:

Human zero trust: never trust the network; verify the identity per request; least privilege; assume breach.

Agent zero trust: all of that — plus verify the compound identity (the agent and whoever it’s acting for), evaluate intent and not just permission, gate every tool call at machine speed, and scope credentials just for the task rather than as standing grants.

The reason the difference matters: the thing you’re authorizing is no longer a person clicking a button. It’s an autonomous, prompt-driven state change in a real system — a record created, a permission granted, an account suspended — that happened because a model decided to make it.

Where this lands

The uncomfortable implication is that listing your agents in a registry buys you nothing. Inventory is not governance. An enterprise will not trust an AI workforce because it can see a list of agents; it will trust it when every action one of those agents takes is identity-bound, intent-aware, policy-checked at the moment of the call, and traceable afterward in plain language.

That’s a runtime problem, not a configuration problem. The enforcement point can’t live in a spreadsheet or a quarterly access review — it has to sit in the path of every tool call, asking the same question zero trust always asked, for a user that finally makes the question hard again: is this principal authorized to do this, right now, for this purpose?

We answered that question for people. Now we get to answer it again — for the agents acting on their behalf.

Recently I was reading about “The Law of Triviality” on a blog. Simply put the law states that given an audience and a set of topics to discuss, most time is always spent on the least important topic.

This law is also commonly known as “bike-shedding” because that is the example Parkinson used to demonstrate this law. Cyril Northcote Parkinson who was a British naval historian, coined this theory in the late 1950s. Surprisingly, this seems to hold true even in today’s corporate setting. It is intuitive to see why this is the case, i.e. people like to discuss things they are most comfortable with. However, I wanted to explore if this could be explained in a more scientific way and that’s when I turned to Game Theory.

For readers who might be unaware, Game Theory is the study of how rational people behave in a given situation. A rational person is anyone who tries to behave in a way that they believe to be the best means to achieve their given ends. In simple terms for any person, there is a utility value associated with every action they can take and they would like to make a choice that can get them a good utility given all circumstances.

To run this experiment, we will consider the three topics to be discussed that Parkinson used to illustrate the law

• A proposal for a £10 million nuclear power plant
• A proposal for a £350 bike shed
• A proposal for a £21 coffee budget

Also, for the sake of simplicity let’s assume there are three people who are going to be a part of this meeting

• Shubham — A nuclear scientist
• Nikunj — Office administrator
• Akshay — A college intern for the PR department

We can make an assumption that the utility that a person gets from the meeting is directly proportional to how much they can contribute to the discussion and what value they get from the outcome.

So, based on their job roles and experiences we can define the following table which denotes the utility that each of them would get when discussing a certain topic.

The above table should be read as follows:

1. When Nuclear Plant is discussed

Shubham will get the highest utility of 5 as she is a nuclear scientist who understands the topic best and can contribute.

Nikunj who is an office administrator can contribute a little but not as much as Shubham and he only gets a utility of 2.

Akshay who is an intern for the PR department can hardly contribute and only gets a utility of 1.

2. When the Bike Shed is discussed

Shubham can contribute fairly well to the topic but doesn’t care about it as much, so she only gets a utility of 2.

Nikunj cares a lot about this and can contribute the most gets a utility of 5.

Even in this case Akshay really doesn’t have much to contribute so he continues to get a utility of 1.

3. When the Coffee Plan is discussed

Shubham can contribute and cares about this but not as much as the nuclear plant so she gets a utility of 3.

Nikunj also can contribute to this topic and he also fairly cares about it but not as much as the bike shed so he gets a utililty of 3.

Akshay can both contribute and cares about this topic so he gets a utility of 4.

I know that the above example is a little contrived and the actual utility values are subjective. But we can make an educated guess that the utility values would be along with the same scales, if not with similar values.

The topics, however, are more nuanced in real life but this example with widely varying topics really helps to drive the point home, so I ask you to indulge with me a little.

By observing the above game table we can see that a “Nash Equilibrium” exists for this game. A “Nash Equilibrium” is a strategy or set of strategies that ensure the best outcome for the entire system.

From the table, we can see that the best strategy here is to discuss “coffee plan” as that ensures that you get the best utility for everyone involved in the meeting. This scientifically proves what we initially hypothesized.

It proves that in meetings we often end up discussing something everyone can contribute and get value out of and in most cases this ends up being something trivial.

How do we fix it?

Now that we have a scientific way of denoting the “game” of meetings, we can clearly conclude that to have more meaningful meetings we need to make sure all or most participants have a high utility from discussing the important things.

We can distill that down into steps as follows:

1. Decide what important topic needs to be discussed.
2. Invite people who can contribute in a meaningful way to the topic.
3. Invite people who set to gain/lose from the outcome of the discussion.

This way you can avoid falling trap to the “Law of Triviality” and have productive meetings with productive outcomes.

Originally published at https://akshaykulkarni.info on April 29, 2020.

Two out of three jobs that I have had, I got them through a referral. My first job right out of college was at Microsoft which I had gotten through on-campus career placement. In some way, even that is a job referral of sorts, my college referred me to my employer.

I got my next two jobs through direct referrals from people within the company who I had built a network with.

I want to share a few insights I have had with my own limited but massively successful experience in getting job referrals. I frequently get messages on LinkedIn from people trying to get a referral, and I see them make some very common mistakes that make it really hard for me to help them.

I will try to cover both a good strategy for getting referrals easily and a few common mistakes you can avoid making while asking someone for a referral.

Build a genuine relationship

My first and most important tip would be to build a genuine relationship with people at your dream company or in your dream job roles. Building a genuine relationship helps make the relationship non-transactional.

It is a lot easier for a person to refer someone they know in some capacity than referring a total stranger from the internet. In fact, if you are able to build a genuine relationship and a good impression, people might reach out to you asking if you would like to work with them.

Demonstrate the required skillset

The next tip is to try to demonstrate that you have the skill set required for the job role you are gunning for. By doing this well, you get people excited about working with you and this increases your chances of getting a referral.

At the end of the day, we all want to work with smart individuals who we can learn and grow with. If you can easily convince someone of your capabilities, this will go a long way in fetching you a referral.

The best way to demonstrate a skillset is by either having an online portfolio or by writing about the subject and engaging with other people in the space.

Work like you have the job

This last tip is a little more nuanced than the other ones but can actually be very effective if done correctly.

Don’t wait for someone to give you the job title or an offer letter, do the job as if you already have it. The idea is to show that not only do you have the required skill set but you are actually passionate about the job itself. This signals that you are in this not for the money or the status but just for the love of it.

For example, if you are an engineer trying to move into product management, don’t wait for someone to officially give you the title. Work with product managers in your company if possible and help them out. If there are no product managers in your company, figure out what a PM does day to day and try to do it.

This helps you both build the skillset and if you do it well it will help you easily transition into that role officially as well.

Another example lets say you are not really changing roles but want to move to a different company in the same role. Try to answer for yourself why you would want to work at that company. If the answer is money or status, you should be asking deeper questions to yourself. But if the answer is that you would actually enjoy working on some projects there, then great. Just picture yourself actually having the job and try to write about your ideas and how you could contribute to it.

It’s important to do this in a constructive positive way and not out of spite or in a way where you are negatively criticizing the company. Remember, people working there have more data than you do so there decisions are more informed.

A good case study for doing something like this is Jason Yuan who got rejected by the Apple Music design team for an internship but he loved the project so much, he went ahead and did it anyway. He later ended up getting the job. You can read more about it here.

I hope that these tips help you get into your dream role at your dream company and would like to hear your feedback or opinions on this.

Growing up, I hated the term luck. I absolutely resented the idea that luck played a major part in success.

For me luck represented an uncontrollable random factor. I wasn’t willing to accept that something out of your control, something completely random played a role in your success.

As Einstein famously said “God does not play dice with the universe”.

Unfortunately, as I grew up I had to start accepting that luck in fact plays a huge role in determining your success. I had to slowly and sadly start accepting that maybe I was wrong, maybe Einstein was wrong too.

It was probable that success was in fact influenced by a random factor.

But all of this changed when I recently read an article by Marc Andreessen called: “Luck and the Entrepreneur, Part 1: The four kinds of luck”.

Initially, it caught my attention but if I have to be honest, I didn’t completely grasp the significance of what Andreessen was talking about. But when I later heard a podcast by Naval Ravikant where he talks about “How to get rich” and makes references to Andreessen’s article it all started making sense.

This probably says a lot about my motivations. However, I am not really ashamed to admit that becoming rich is a huge motivation for me. For some weird reason there is a social stigma around aiming to become rich. I do want to help other people and the society but I believe that becoming rich will afford me the leverage and freedom to do so.

But getting back to the article, Andreessen talks about four kinds of luck and only one of which is completely random. The four types being

• Blind Luck — This type of luck is completely random and accidental. This is what most people associate being lucky with.
• Motion — This is the type of luck that you make for yourself by stirring the pot. One way to think about it is, ‘If you take enough shots, you will hit one of them’.
• Recognizing Good Fortune — This is the type of luck where you have develop a keen sense and understanding of a field. So you can pick up signals that others can’t and get lucky. Louis Pasteur characterized it for all time when he said, ‘Chance favors the prepared mind.’
• Directed Motion — This is the most complicated type of luck. This happens when you have established yourself in a field as an expert and instead of you finding luck, luck finds you.

So what does this mean for us. Well for starters, even though luck plays a factor in success, it is not completely random. It is something that can be hacked. You can set yourself up to get lucky.

I have come up with a simple 4 point framework to increase your chances of getting lucky. It has worked fairly well for me so far.

1. Pick a field and stick to it

Pick a field that you are excited about and think is going to grow in the future. The first condition is more important than others. You need to be excited about the field or you won’t stick with it. Having an intuition about the future is a skill you can learn over time and is subject of a different article. By picking a field and sticking to it, you increase your chances for the second type of luck.

2. Find the best people, companies or projects in the field

A lot of luck comes from being in the right place and having leverage and the means to act on it. Working with smart people in the field affords you this opportunity. It will help you both understand the field and build your expertise in it. This increases your chances for the third and fourth type of luck.

3. Strive to establish yourself as an expert

Use the resources and people around you to try to become an expert in the field. Also try to communicate and share your ideas with the world. It’s no point in becoming an expert if no one else can testify to that. This opens yourself up for the fourth kind of luck.

4. Keep your eyes and nose open to exciting opportunities

If you stick to a field and become an expert in it, lots of new opportunities will open up for you. But it is still up to you to recognize these opportunities and act on it. This step is more about making the best of the luck afforded to you.

I apply this framework rigorously and it has so far worked beautifully. I would love to know if it works for you or any other comments you might have. Comment below or hit me up on twitter.

How to Increase your Chances of Getting Lucky was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

tl;dr Because of Guilt

Last week I had a long altercation with a friend leading to some interesting insights into my own belief system. She was annoyed because I paid extra for a cab ride rather than paying what the fair price by a meter would have been.

It is common where I live for the cab drivers to quote their own price rather than use the meter onboard the vehicle. Most people just haggle the price down to a lower value than what was quoted but still higher than the meter price.

My friend was very annoyed with me because I refused to partake in this tradition of a 5 minute argument to get the price down by 10 bucks. At first she tried to explain how I was being cheated by cab drivers and when that didn’t work concluded that I don’t haggle because I am uncomfortable or even incapable of having an argument or a haggle debate.

I didn’t care much about her explanations but when my competency for a task was questioned, my ego rushed in and I knew I had to defend myself. I hate being told that I am not good at or can’t do something (more on that in a different article maybe). And in this particular case I knew that she was wrong.

Not only am I comfortable in fact I love having arguments and debates. Most of my close friends would agree with this begrudgingly but you can’t beat me in an argument. She however didn’t know this as we weren’t very close.

I still had to defend myself so I started introspecting my own actions and why I don’t haggle. After a lot of introspection I realised that the reason I don’t haggle with cab drivers, street vendors or anyone else is for the same reason.

The reason is Guilt. I feel guilty because I was lucky to be where I am and they probably weren’t.

My friend was trying to explain it to me as to how it is not fair to pay extra money and how I was being unfairly taken advantage of. She was right about one thing and that was that the whole ordeal was unfair. But I believe that there is something more unfair at play if you can just look at it differently.

It is unfair that I had access to good education and opportunities while the cab driver probably didn’t. It’s unfair that the vendor you haggle with was born to an alcoholic dad and an illiterate mom in a poor household where they couldn’t support his or her education.

When you put the unfairness of circumstances of birth versus unfairly being charged more money, the former triumphs as the greater injustice.

Also that extra ten bucks probably means more to the vendors than it does to you. The marginal value for you (who has more money) of the ten bucks is lesser than what it is for a poorer person. That’s very simple economics. It’s called the law of diminishing marginal utility.

Maybe I am right about how I think about this or maybe I am wrong. But empathy is a beautiful thing and if only more people even partially practiced it the world would be a better place for everyone.

When Facebook announced the Messenger platform for building chatbots a couple years ago, there was a lot of excitement in the market. Everybody was of the belief that bots are the next biggest thing in technology. In fact it wasn’t very hard to find an article with the title along the lines of “How chatbots will replace mobile and web applications” published everyday.

New tools ranging from code libraries, drag and drop tools, GUI based bot builders, mockup tools and analytics platforms were being launched within weeks of each other. Some of these tools were able to achieve amazing success like Chatfuel and ManyChat in the GUI bot builder category, Dashbot and Botanalytics in the analytics platform category and Microsoft Bot Framework and Botkit in the coding library category.

For all the hype that the launch of these tools and platforms generated there seems to be a growing belief that chatbots have not lived up to their initial promise. This is primarily because the promise was maybe wrong. Part of the promise was to have human level conversations and the reality is currently we do not have the level of Artificial Intelligence required to achieve completely human like interactions. The other more misleading promise was that bots will replace mobile and web apps. As I mentioned earlier almost every second person working in the chatbot space was pushing bots to be the replacement for apps. This led to developers trying to re-implement mobile applications as chatbots. And in most cases the bots were a poor re-implementation of the apps functionality. Nothing more, almost always less. The few bots that have tasted success are the ones that have completely reimagined their solution through a conversational perspective.

All of these factors have led to doubts beginning to creep about chatbots as a market opportunity. Many people have started to question whether the whole chatbots thing is a hype bubble that is eventually going to burst and some actually believe that the burst has already happened. The recent embargo by Facebook on building new chatbots also hasn’t helped much to alleviate these fears.

However, I still believe that the world needs chatbots and the reasons are pretty simple. Actually at the heart of it there is only core reason which is conversations are a more natural way to interact than UI. A lot of people disagree with this saying pointing and clicking at things is more natural to humans as this is what we did as babies. But this is true only if you are pointing at colourful pictures, not trying to figure out which button or link to click in a 3 level menu. I actually believe that communicating through voice is more natural and the only reason babies point at things is because they have limited conversational ability.

Using an UI might feel very natural to most of the readers of this article but that is mostly because in most of you have been exposed to technology for a very long time now. If you really feel UIs are more intuitive try asking old aged people who aren’t as used to technology to use an application. GUIs are very hard to use for someone who hasn’t been exposed to technology and there are many such people, especially in developing markets. In markets like India a huge majority of the population is just getting connected to the internet and starting to use smartphones. From personal experience of talking to such people I can tell that its very hard for them to understand and use GUIs because they are not used to them. The one thing they are used to is normal human like conversations. This provides a huge opportunity to developers like us to solve problems for this new generation of users with chatbots that are able to converse with these users in their regional languages.

Chatbots can also help solve problems in areas which haven’t kept up with technological progress as much such as education, healthcare, banking etc. Chatbots help remove the technology apprehension that the people in these sector might have and also provide a way to provide new and more intuitive solutions to problems in these areas.

To conclude I believe that currently we are just going through the disillusionment phase of the Gartner cycle and chatbots as a market will take of in the next couple of years.

If you are a developer and want to learn about building chatbots for these next generation of users and new solutions for the industries lacking behind in progress do check out my book on Building Chatbots with Microsoft Bot Framework and Node.js.

Why the World Needs Chatbots was originally published in Chatbots Magazine on Medium, where people are continuing the conversation by highlighting and responding to this story.

Its time to debunk the hype and get back to reality and customer experience basics. But don’t get me wrong I am not against chatbots or conversational interfaces. On quite the contrary I am a huge believer in conversation as a platform and my startup Ozz aims to provide services to help make your bots/conversational apps smarter. I believe that conversational platforms are going to be huge in the coming years. This post however is not about my startup so let’s get to the real issue.

Why not bots?

The aim of any company/service/software should be to be ease a customer pain point not to glorify some technology. Or in other words your customers don’t really care if your service is a AI bot or a bot with cards or an app or a website. What they really care about is, is there problem solved.

And in some cases bots are not the right solution, let me try to give you some examples. I will name a popular app but the reasoning should apply to any app in the category

1) Uber (Cab booking in general)

I use uber on a regular basis and even though a bot for uber might seem pretty straightforward, I just send a message

Book me a cab

give my location and bam I have a cab. However there is a very important feature of uber I won’t have anymore to see if there are cabs around before booking and track the cab on the map once it’s booked. This might not seem very important to you, but it is to me and to a lot of other people or uber wouldn’t have invested in it.

So how would I do this in a bot? Keep asking “Where is the cab?” or have it reported automatically every 5 mins. Both get very annoying very quickly.

2) Instagram/Facebook/Twitter (Any app with a feed)

How would you represent a ordered feed, keep sending me messages. Twitter/Facebook used to send and sometimes still send SMS notifications for birthdays, comments etc and its super annoying. Imagine getting a message anytime something is added to your feed.

3)Book My Show/Make My Trip (Movie/Flight Booking)

For some reason this category seems to be pretty famous and I might be wrong about this but the user experience on the app is way better than what it would be on a bot.

Let me show it actually

Booking movies

Step 1 ) Click on movies

Step 2) Choose movie from list

Notice how easily I can switch the dates to find show availability.

Step 3) Select seats

And thats it. That’s 3 clicks. The bot alternative would be back and forth messaging, multiple times if you want to check tickets for different dates. It is a no brainer as which of the two provides a better experience. ( I didn’t include any bot screenshots as I don’t want to insult or hurt any developer’s sentiments)

PS: I do not have any affiliation with Book My Show

4) Games

How do you make a bot for temple run? A HTML 5 webview based game in messenger doesn’t count as a chatbot, sorry!

The Counter Argument

If you bring up these points there are a common set of counter arguments you will get. They are

1) People don’t download apps anymore.
2) The UI of chatbots will evolve to provide more features.

So I will try to provide my arguments against both these points

1) People don’t download apps

I would argue that is not entirely true, most of published research around it seems to only take into account the download numbers of top apps. But by being top apps that are widely adopted, there is going to be a slowdown/saturation at some point. This in no way is indicative of the entire app market as whole.

Also as smartphones keep getting better every year, memory and CPU are no longer a restriction.

The bottomline is if you are solving a real problem in a good enough way people will download your app. In fact apps have an advantage over bots as they are more discoverable than bots but that might change.

The challenge is to get users to click on download. But that is a call to action challenge which is pretty much platform independent.

There are cases where a bot is better than app but I will get to that later in the post.

2) The UI will evolve

I am sure the UI will evolve to provide more GUI options like lists, carousels, dropdowns, maps etc. But the more GUI you get into a bot the less it is a conversational bot and more it is an app. This very well might be the future. But you can’t call these things chatbots just because they live inside messenger/telegram.

A better name would be messenger app/ telegram app

This might be the future messenger apps living in the messenger store. But apps not bots.

When are chatbots the better option?

That’s too much negativity in one post, so lets talk about some positives, use cases where bots actually make sense.

1) One time use problems

If there are problems that aren’t very frequent but big enough users might be better served by having a bot instead of apps. Some examples are

• Scanning QR code
• Getting Wifi info at public places
• Booking appointment with Doctor/Lawyer ( If you need them regularly you probably have a personal connection and don’t use an app)

2) Customer Support

This is the most obvious case, but the NLP technology might not be ready for a fully automated service and a hybrid (human + AI) would be an ideal solution.

3) Human Replacement

In general the best bots are the ones which replace an actual human based role. So instead of conversing with a human you do so with a bot. Customer support is a subset of this. But in general anything like scheduling assistant, personal assistant etc.

4) Complex UI

I believe that this is the biggest opportunity for chatbots. Applications where the GUI is super complicated and you have to train people to use it.

A very good example I like to give for this is Photoshop. I have been wanting to learn to use photoshop I still don’t. But imagine if I could just upload an image and tell photoshop through voice or text the changes I want and it does it. That would be super cool wouldn’t it!

The hype is damaging the field and leading to people doubting the entire field. I hope in 2017 people start focussing on problems and solve real customer pain points and if the best way to solve it happens to be through a bot (there are lot of these, trust me), then by building a bot. It’s going to be an exciting year, nevertheless.

Originally published at blog.ozz.ai on January 7, 2017.

Today was my last day at Microsoft. I decided to quit my job after 1.5 years of an amazing learning experience. In all my time here I don’t think there has ever been a time where I regretted joining Microsoft. Sure there were moments where I wasn’t happy with the way things were shaping up but that’s part of the journey.

Overall I think Microsoft is one of the best things that has ever happened to me. Making the decision to leave wasn’t an easy one and was made after a lot of contemplation and thought put into it.

I apologize beforehand but this is going to be a long post. For people who need a quick summary, this is it

I know startup is what I want to do and there is no better time than now

So Why did I Quit?

I don’t really remember why but by the end of my third year in college, I knew that I wanted to one day start my own company. Maybe it was the joy of making something and see other people use it and have full control over the process or maybe it was me just following the Fad.

I had started working on my own startup Intigrent, where we were basically trying to make an online course platform with a few new features. We wanted the online courses to be more personalized. Maybe it was a good idea, maybe it was a terrible idea. I will never know because 9 months into the startup me and my co-founder had a fight and we decided to part ways. I graduated college and joined Microsoft after this.

I continued working on the idea on weekends and brought in a new co-founder. She was my best friend at the time. We made a pivot in the idea because we felt making content would be a huge challenge. So instead we decided to focus on leveraging existing online content and making personalized curriculum for school kids. But 5 months into the startup, she and I had a personal falling out which was also a death blow to the professional relationship.However I still believe that this is a very good idea but maybe I am not the right person to build it.

So by now I had experienced both losing personal relationship due to professional fight and losing professional relationship due to personal fight. The personal fight however had a big impact on me and maybe in some ways I am still trying to cope with it. But post these 2 experiences I thought maybe startups weren’t my thing and I should just get back to regular work and try to build a strong career at Microsoft.

And I tried, I tried really hard to put all my focus on my work at Microsoft. But I would always get excited when I heard a new startup idea or came up with one myself.

After-all the heart wants what it wants

I was just starting to explore what chatbots meant during this time by building a few useless fun bots like pokedex and a personal resume bot. But as I explored more about this field I realized that 98% of the chatbots out there suck and this was an AI problem and not how easy it to build a bots problem. So I came up with the idea of http://ozz.ai which helps people make smarter chatbots.

I was pretty convinced that this is what I wanted to work on and made the decision to quit. It was a hard decision to quit my comfortable, well paying job but I only had to answer one question, whats the downside?

I think most people think of risk the wrong way. There is no risk in quitting a job, the risk is in staying back. Think of it this way. You are 23, have no family to take care of, can survive on fast food and have a long career ahead of you. This exact combination happens once in your life, just once. You will have 100s of opportunities to work for a big company but you are 23 only once.

Having realized that, the decision was pretty much made and I was lucky that my parents understood my point of view and supported me in this.

Why not work on it part-time?

By far this is one of the most common questions I get. “Why don’t you work on this in your free time?”, “Why don’t you work on this during weekends?”

I believe that this a fundamentally wrong approach. Startups are hard, I know from my two failed experiences that there are so many things that can go wrong and most of them at some point will. You need a lot of focus and will to get over these and keep moving on. I think startups are one of those things where you are either all in or you are not. There is no middle ground.

Reid Hoffman, founder of LinkedIn, famously said starting a startup is like “throwing yourself off a cliff and assembling an airplane on the way down.” To start a startup while having a day job is like throwing yourself off a cliff but with a parachute on. When things get hard you are going to deploy the parachute.

The only way to maximize your odds of actually building the airplane is to have no parachute, no backups and nothing to go back to.

What’s next?

I am not sure if ozz will work out or not but the one thing I am sure of is, I won’t have regrets. And the failure wouldn’t have been for lack of trying.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Why I quit my job at Microsoft to start a Startup was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unless you have been living in a cave with no internet access, you must have heard about how chatbots are the next biggest thing and how they will completely replace apps. The jury is still out on whether that’s true.

But we can’t ignore the fact that all major companies have been betting on this new field. Facebook, Microsoft, Google, Amazon are all in on the craze.

Microsoft’s offering ‘Microsoft Bot Framework’ is the most interesting offering according to me (disclaimer: I used to work at Microsoft). It lets you easily build bots for multiple platforms like

• Facebook Messenger
• Slack
• Telegram
• Kik
• SMS (twilio)
• Email
• Skype
• Skype Teams

You can write code either in node.js or C#. The best thing however about the framework is how easy it makes to maintain and store data through multiple databags like SessionData, UserData and ConversationData.

Natural Language Processing is a very critical piece for building amazing chatbots. Microsoft Bot Framework lets you easily do this by providing built-in support for luis.ai (part of microsoft cognitive services offering for language processing). However not everyone might want to use LUIS as it requires you to have an azure subscription (starting dec 31).

So I coded up a small npm module api-ai-recognizer to use Dialogflow (previously api.ai) instead of LUIS with microsoft bot framework. In this tutorial I will show you how you can build a simple weather bot using api.ai and Microsoft Bot Framework.

Tutorial

I apologize for the long intro but I felt it was important to set context. So let’s get started with building the bot.

We will be using node.js for building the bot and then deploy it to Microsoft Bot Framework Service. You can then deploy it to a channel of your choice.

Btw, if you are the sort of person who would prefer skipping right to the end, here’s the github link to the code: full code link

Step 1: Set up Environment

Make sure you have node.js and npm installed.

The first thing we have to do is create a directory so lets go ahead and create a directory called weather-bot. Now cd into the directory.

mkdir weather-bot cd weather-bot

Now lets initialize npm so we can download the required packages. Run the following command and accept all the defualt options.

npm init

Verify that npm has been initialized by checking if a file called package.json has been created. Once you have verified that lets install the required packages.

To start off we only need two packages

1) botbuilder — For using microsoft bot builder
2) api-ai-recognizer — For using api.ai for NLP

Let’s go ahead and install both packages by running the following command

npm install --save botbuilder api-ai-recognizer

Step 2: Create a basic echo bot

So in this step we will create a very basic bot that will just echo what we say. It’s pretty dumb but it’s a start and in the next steps we will build on top of it.

Once the npm packages have installed, create a file called index.js in the root directory and paste in the following code

var builder = require('botbuilder'); var connector = new builder.ConsoleConnector().listen(); var bot = new builder.UniversalBot(connector); bot.dialog('/',function(session){ session.send("You said %s", session.message.text); });

Note : For this simple case we are using ConsoleConnector as it lets us test the bot from our console directly.

You can test the bot by starting the node server and directly chatting on the console.

node index.js hi You said hi hello You said hello

Step 3: Create the natural language understanding model

In this step we will be building a natural language processing model on api.ai so that our bot will be able to understand human language queries like

what’s the weather in new york tomorrow?

The first thing is to head to Dialogflow and create an account.

Next create an agent called weather-bot by filling in the required details

The next step is to create an intent. An intent is basically a way to figure out what the intended action is for a given natural language text.

So let’s create a intent called whatIsWeather to classify all queries where a user wants to find out the weather. (It’s not neccessary to name your intents without spaces. It’s just a convention I like to follow.)

Give the following example utterances

• What is the weather?
• what’s weather like now?
• how is the climate?
• how’s the weather?

In a real application you would provide more examples but for the purposes of this demo these should do good.

You can give it a response if you want but we won’t really be using it in this demo.

Once you have created the intent you can save it and check if it’s working by using the try it now chat section on the right side of the website. You should be able to see that the intent gets recognized.

Step 3: Connect api.ai with Microsoft Bot Framework

This is the step where the magic happens. But before we connect api.ai to our code we need to grab the client token. To do this just click on the agent dropdown and select view all agents.

Select the weather-bot agent from the list of agents and you should be able to find your client access token there

Now change index.js as the following code to make the connection

var builder = require('botbuilder'); var apiairecognizer = require('api-ai-recognizer'); var connector = new builder.ConsoleConnector().listen(); var bot = new builder.UniversalBot(connector); var recognizer = new apiairecognizer(<api.ai token>); var intents = new builder.IntentDialog({ recognizers: [recognizer] }); bot.dialog('/',function(session){ session.send("You said %s",session.message.text); });

Note: Don’t forget to put in your client token

This code basically creates an intent recognizer which will try to recognize any incoming text based on our api.ai model.

Now lets use it. Replace your previous bot.dialog code with the one below

bot.dialog('/',intents); intents.onDefault(function(session){ session.send("Sorry...can you please rephrase?"); });

Basically what we are doing above is pass all the messages to the api.ai intent recognizer and then setting up a default handler. This is where you put your infamous “Sorry..I couldn’t understand” type of messages.

Once having added this code, try to run it. It should give the default response to anything you say, because we only specified the default case.

Let’s add the handler to recognize the whatIsWeather intent we created earlier.

bot.dialog('/',intents); intents.matches('whatIsWeather',function(session){ session.send("It's 27 degrees celsius"); }); intents.onDefault(function(session){ session.send("Sorry...can you please rephrase?"); });

We have hardcoded the response right now but we will hook it up to an API later.

If we run the app now, it should be able to recognize the statements which are similar to the ones we trained the intent with before.

node index.js whats the weather It's 27 degrees celsius Hi Sorry...can you please rephrase?

Even though the bot just says 27 degrees all the time we have made some progress. We have a functional bot.

Before we make it more accurate by getting some real weather data, lets add a few interesting things.

What I have observed from making a few fun bots is users expect your bot to be good at smalltalk at the least good at handling greetings like hello, good morning and other such stuff.

We could train our api.ai models to understand this but there is a easier way, thanks to the good people at api.ai. They have pre-built training for a few domains.

You can turn on/off domains by clicking on the domains tab in the left menu. For this demo we will be turning on the smalltalk domain.

Once you have turned the smalltalk domain on we need to plug in some code to make sure our bot handles this. To handle all smalltalk greetings, we will add a new handler to recognise the intent smalltalk.greetings.

intents.matches('smalltalk.greetings',function(session){ session.send('This is smalltalk'); });

Here we are basically logging out the fact that we understand that the phrase user sent is smalltalk of type greetings. Not super useful to the user, but good for us for debugging. Save the file and run the code.

node index.js hi this is smalltalk good morning this is smalltalk bye this is smalltalk

This is super cool. Even though we have not trained our bot to understand any of these phrases manually, it understands them, thanks to Domains.

One more great thing about domains in api.ai is it not only helps your bot understand smalltalk phrases but it also has preconfigured replies (you can edit/customize it though). Let’s use these in our bot. These are called fulfillments. Plugin the following code to use fulfillments.

intents.matches('smalltalk.greetings',function(session, args){ var fulfillment = builder.EntityRecognizer.findEntity(args.entities, 'fulfillment'); if (fulfillment){ var speech = fulfillment.entity; session.send(speech); }else{ session.send('Sorry...not sure how to respond to that'); } });

Please note the additional args argument passed to the callback function in the handler. Don’t worry about all the entity stuff in the code. I will explain that in a while.

Now save the code and restart the app to test it.

node index.js hi Hey. good morning Top of the morning to you!

The exact replies might be different for you because the replies are selected randomly from a list of possible replies. But the reply should be something sensible.

Step 4: Get Weather Data from API

In this step we will be getting the real weather data from the APIXU current weather api.

The API will require one parameter, the city name whose current weather data we will need.

We will get these parameter out of the user’s query and if he doesn’t provide it, we will explicitly ask the user to provide a city name.

These parameters in NLP terms are called entities and we will have to train our api.ai models to understand and extract these entities. So lets do that.

Click on entities in the left menu and select create new entity and create a new entity called cities and put in some example city names.

In a real world scenario you would be using pre-built entities which have already been trained with a lot of examples. But we will make do with this for the purposes of this bot. Don’t forget to click on the save button once you are done adding examples.

Now lets train api.ai to understand the cities entity. Go back to intents and click on whatIsWeather intent. Let’s add a few examples which have city name in the sentence.

Something like

What’s the weather in paris?

The entity should be auto detected. Make sure its your entity and not a prebuilt entities. Prebuilt entity names have the format sys.name. Add a few examples and then save the intent.

Now lets add some code to pull out the entity information from the phrase. It will be very similar to the fulfillments code.

intents.matches('whatIsWeather',function(session,args){ var city = builder.EntityRecognizer.findEntity(args.entities,'cities'); if (city){ var city_name = city.entity; session.send("It's 27 degrees celsius in " + city_name); }else{ session.send("It's 27 degrees celsius"); } });

Now if you save and restart the app, it should be able to get the city info.

node index.js what is the weather in paris It's 27 degress celsius in Paris

We however have to still handle the case where city is not given. We can do this by issuing a prompt to user asking him for a city name. Here’s the code to do that

intents.matches('whatIsWeather',[ function(session,args){ var city = builder.EntityRecognizer.findEntity(args.entities,'cities'); if (city){ var city_name = city.entity; session.send("It's 27 degrees celsius in " + city_name); }else{ builder.Prompts.text(session, 'Which city do you want the weather for?'); } }, function(session,results){ session.send("It's 27 degrees celsius in " + results.response); } ]);

Okay there is a lot going on in there. So let me break it down. Microsoft bot framework lets you chain functions for handlers by passing in an array of functions. You can use this to run functions one after other collecting data and using it in the next function. You use prompts to ask for data. You can read more about this in the official documentation.

Now you can save the app and restart and it should prompt for city if you don’t provide it.

node index.js what is the weather? Which city do you want the weather for? orlando It's 27 degrees celsius in orlando

Now that we have this working, lets hook it up to the api and get real weather data.

So firstly create an account for yourself on APIXU. Once you do that you will get a API Access Key and you can play around the API by clicking on getting started. Put in a few city names and get a feel of how it works.

Keep your api access key handy we will be needing it to make the api calls. We will be using the request module on npm to make the calls, so lets start by installing it.

npm install --save request

Once we have request installed lets require it by adding in the following lines at the top of index.js

var request = require('request');

Now that we have access to request module lets put in code to get weather data from API

intents.matches('whatIsWeather',[ function(session,args){ var city = builder.EntityRecognizer.findEntity(args.entities,'cities'); if (city){ var city_name = city.entity; var url = "http://api.apixu.com/v1/current.json?key=<Your API Key>&q=" + city_name; request(url,function(error,response,body){ body = JSON.parse(body); temp = body.current.temp_c; session.send("It's " + temp + " degrees celsius in " + city_name); }); }else{ builder.Prompts.text(session, 'Which city do you want the weather for?'); } }, function(session,results){ var city_name = results.response; var url = "http://api.apixu.com/v1/current.json?key=<Your API key>&q=" + city_name; request(url,function(error,response,body){ body = JSON.parse(body); temp = body.current.temp_c; session.send("It's " + temp + " degrees celsius in " + city_name); }); } ]);

NOTE: Don’t forget to put in your API key

Once you save and restart your app, it should be working as expected.

node index.js whats the weather in paris It's 4 degrees celsius in Paris whats the weather Which city do you want the weather for? Beijing It's -4 degrees celsius in Beijing

Step 5: Deploy your Bot

In this final step we will be deploying our bot and then you can use Microsoft Bot Connector to connect it to channels of your choice.

We will be using heroku for hosting as it is pretty straightforward and has a free tier.

First lets set up version control

git init

Before adding and committing the files lets add a .gitignore to ignore node_modules folder as we don’t want to version control or deploy this.

Add a file called .gitignore in the root folder and paste in the following

node_modules/

Now lets add and commit the files

git add . git commit -m "basic bot setup done"

Download and install heroku on your system following instructions from here.

While it installs add a new file called Procfile to root folder. This file will tell heroku what command to run to start your web. Paste in the following into the file.

web: node index.js

Before we deploy there are a few code changes we need to make in index.js

We need to install a few npm modules to get this done. So run the following command.

npm install --save restify

Once the install is done, replace the following code

var builder = require('botbuilder'); var apiairecognizer = require('api-ai-recognizer'); var request = require('request'); var connector = new builder.ConsoleConnector().listen();

with

var builder = require('botbuilder'); var restify = require('restify'); var apiairecognizer = require('api-ai-recognizer'); var request = require('request'); //========================================================= // Bot Setup //========================================================= // Setup Restify Server var server = restify.createServer(); server.listen(process.env.port || process.env.PORT || 3978, function () { console.log('%s listening to %s', server.name, server.url); }); // Create chat bot var connector = new builder.ChatConnector({ appId: <MICROSOFT_APP_ID>, appPassword: <MICROSOFT_APP_PASSWORD> });

You can get your Microsoft APP ID and APP Password by registering your bot on the Microsoft Bot Framework Service

For now leave the Messaging endpoint field empty. We will get back to it.

Once you put in the Microsoft App ID and password into the code, run the following commands to deploy to heroku.

heroku create git push heroku master heroku open

The last command must open the heroku url where your bot is hosted. Copy it and go back to your bot registration on Microsoft Bot Framework site.

Paste in the url in the messaging endpoint. Add /api/messages to the end of the url.

Messaging Endpoint : http://.herokuapp.com/api/messages

Save the configuration and your done. Now you can deploy it to channels of your choice by following the excellent documentation on the site.

Congrats on building a fully functional weather bot.

Originally published at http://blog.ozz.ai/using-api-ai-with-microsoft-bot-framework/ on December 6, 2016.

Using Dialogflow with microsoft bot framework was originally published in Chatbots Magazine on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before we start going into the reasons let’s define the terms as there seems to be a huge misunderstanding around them. Wikipedia defines feminism as

Feminism is a range of political movements, ideologies, and social movements that share a common goal: to define, establish, and achieve political, economic, personal, and social rights for women that are equal to those of men.This includes seeking to establish equal opportunities for women in education and employment.

The keyword in the above definition is EQUAL. Also for some reason there seems to be a taboo around the word feminists. But I don’t see any reason behind it. I am a feminist and I am proud of it. To be honest I feel sad that I have to point it out that I am a feminist, everyone should be. It should be the natural state of things.

Next let me define what I mean by anti-feminists. I do not refer to people who do not believe that women deserve equal rights. I am referring to the people who have misunderstood the meaning of feminism to mean female dominance or female superiority.

I see complaints against feminism everyday on the social media and some of them are plain stupid.

The general theme of all complaints is however the same.

A girl/woman tried to take or took advantage of the fact that she is a girl/woman and the whole feminist movement to get some unfair advantage

People get really emotional over this even calling for a total stop on the feminist movement and criticising feminism.

But let’s analyse the argument. It basically says a person from one gender got an undue advantage based on their gender and nothing else. And this pisses them off because it happened to them once or maybe twice. But if they could understand that women have been going through this for generations they will probably understand the magnitude of being pissed off the women deserve to be.

If one such incident in your life could piss you off so much imagine how it would feel to have it everyday of your life for generations together.

And once they get this perspective and understand the pain they could be the strongest proponents because they have experienced undue advantage to a gender albeit in a fraction of what the women actually face, but they get the pain nevertheless. They will be the strongest feminists as this is the exact thing that feminism is trying to fight, undue advantage based on gender.