Every piece of software you use today was built around a single assumption. Someone with fingers is sitting in front of a screen. Buttons imply intent. Wizards manage complexity. Forms structure human thought. This architecture has governed decades of product design because, until recently, only humans clicked.
That assumption is now broken. AI agents do not read interfaces. They do not benefit from helpful tooltips or confirmation dialogs. When an autonomous system needs to act on behalf of a user, the chrome gets in the way. The result is a growing mismatch between how products are built and how modern callers actually behave.
The Click Paradigm
Traditional software relies on a visual contract. A human sees a button, understands the label, and decides whether to press it. Workflows are padded with friction on purpose. Multi-step wizards exist because people make mistakes and need guardrails. Dropdowns and radio buttons constrain input because freeform text invites chaos.
This works well when the operator is a person. It collapses when the operator is an agent. A machine does not need a five-step wizard to cancel a subscription or modify a record. It needs a clear statement of what operations exist and a definitive answer about whether it is allowed to perform them. When teams ignore this, they usually reach for two shortcuts.
First, they hand the agent an API key. Second, they wrap the existing user interface inside a chatbot and call the integration complete. Neither approach solves the real problem.
An API key answers the question, “Did this request come from a trusted source?” It never answers the question that matters: “Can this specific caller read this specific record?” A key is a skeleton key. Once issued, it typically grants broad access across resources and contexts. It knows nothing about the policy governing individual actions inside your system.
Wrapping a GUI in a chatbot is even more fragile. The agent inherits every human-centric assumption baked into the interface. It simulates clicks through modals and forms designed for eyeballs, not autonomous logic. The chatbot might navigate the chrome successfully, but it does so without understanding. It is automation theater. Underneath, there is still no machine-readable contract about what is permitted.
What agents need is not another key to the front door. They need gates.
What Gates Actually Do
A gate is a governed execution layer. Instead of trusting a credential and hoping the caller behaves, a system with gates evaluates every request against declared rules. These rules exist independently of any interface, human or otherwise.
A proper gate defines four things. It declares which actions exist inside the product. It states who can invoke them under what conditions. It specifies when a caller must stop and request explicit consent before producing side effects. And it ensures the system logs every decision in a structured, queriable trail.
This is fundamentally different from traditional access control. Role-based systems often ask, “Are you an admin?” at the door and then let you roam the building. Gates ask, “Are you allowed to flip this specific switch right now?” at every junction. Identity becomes secondary to behavior. The policy travels with the action.
To make this concrete, imagine an agent that needs to refund a customer. A key-based approach might let any bearer of the key process the refund if the endpoint is reachable. A gate-based approach checks the manifest of available actions, verifies the agent’s permission against the specific customer record, requires explicit user approval for the financial side effect, and writes the entire sequence to an audit log. The gate enforces policy, not just identity.
Testing It on Whistler
We put this model to work on Whistler. Rather than building separate pipelines for humans and machines, we wrote a single policy layer and ran two different callers against it.
One caller was a human using the embedded Shell. The other was a third-party agent developed outside our team. Both connected to the same manifest. Both faced identical permission checks at every step. When either caller attempted an action with side effects, like modifying data or triggering an external event, the system required explicit approval. Every request, approval, and denial generated the same structured audit trail.
কোনো পক্ষই কোনো মাস্টার API কী ব্যবহার করেনি। সেখানে কোনো ব্যাকডোর ছিল না, বা পলিসি বাইপাস করার মতো কোনো উচ্চতর ক্রেডেনশিয়াল ছিল না। একজন মানুষ শুধুমাত্র পাসওয়ার্ড এবং ব্রাউজার থাকার কারণে শিথিল বিধিনিষেধ পায়নি। একজন এজেন্ট শুধুমাত্র মানুষের মতো ফিঙ্গারপ্রিন্ট নেই বলে যথেচ্ছ ব্লকের সম্মুখীন হয়নি। গেটটি অ্যাকশন, প্রেক্ষাপট এবং নিয়মগুলো মূল্যায়ন করেছিল। পুরো লেনদেনটি ঠিক এটুকুই ছিল।
এর ফলে এমন একটি সিস্টেম তৈরি হলো যেখানে নতুন কোনো কলার (মানুষ বা মেশিন) যুক্ত করার জন্য অ্যাক্সেস লজিকের কোনো রিফ্যাক্টরিং করার প্রয়োজন পড়ল না। আপনি শুধু পলিসি আপডেট করলেন এবং গেট সেটি কার্যকর করল।
প্রোডাক্ট সংক্রান্ত প্রশ্নটি নতুন করে ভাবা
আপনার টিম যদি বর্তমানে মানুষের তৈরি কোনো প্রোডাক্টে কীভাবে AI এজেন্ট যুক্ত করা যায় তা নিয়ে ভাবছে, তবে সম্ভবত আপনারা ভুল প্রশ্ন দিয়ে শুরু করছেন। টিমগুলো সহজাতভাবেই প্রশ্ন করে যে তাদের একটি API প্রকাশ করা উচিত কি না। পরিবর্তে তাদের প্রশ্ন করা উচিত যে প্রতিটি কলারের জন্য তাদের একটি নিয়ন্ত্রিত এক্সিকিউশন লেয়ার (governed execution layer) আছে কি না।
গেট ছাড়া একটি API হলো কেবল একটি বড় দরজা মাত্র। যদি আপনার অভ্যন্তরীণ পলিসিগুলো কেবল উইজার্ড লজিক, ফর্ম ভ্যালিডেশন এবং মানুষের পড়ার উপযোগী হেল্প টেক্সটের মধ্যে সীমাবদ্ধ থাকে, তবে আপনি যে এন্ডপয়েন্টই প্রকাশ করুন না কেন, তা স্বায়ত্তশাসিত কলারদের (autonomous callers) জন্য নিরাপদ হবে না। এজেন্ট হয় একটি কী-এর মাধ্যমে অতিরিক্ত বিশ্বাস পেয়ে যাবে, অথবা একটি চ্যাটবট র্যাপারের মাধ্যমে ভঙ্গুর পুতুলনাচের মতো কাজ করবে।
প্রথমে গেট তৈরি করার অর্থ হলো আপনার প্রোডাক্টের প্রতিটি অর্থবহ কাজকে একটি ঘোষিত অপারেশন (declared operation) হিসেবে তালিকাভুক্ত করা। এর অর্থ হলো ইউজার ইন্টারফেস থেকে পারমিশন চেককে আলাদা করা, যাতে একজন Shell ইউজার এবং একজন বাহ্যিক এজেন্ট উভয়কেই একই রানটাইম এনফোর্সমেন্টের মুখোমুখি হতে হয়। এর অর্থ হলো কোনো ডেটাসেট মুছে ফেলার মতো ধ্বংসাত্মক কাজের জন্য প্রয়োজন হওয়ার আগেই কনসেন্ট হুক (consent hooks) যুক্ত করা, এজেন্ট ভুল ডেটাসেট মুছে ফেলার পরে নয়। এবং এর অর্থ হলো এমন অডিট ট্রেইল তৈরি করা যা সিকিউরিটি এবং কমপ্লায়েন্স টিম কলারটি মানুষ নাকি মেশিন তা বিবেচনা না করেই পরীক্ষা করতে পারে।
এর জন্য একটি প্রকৃত আর্কিটেকচারাল পরিবর্তনের প্রয়োজন। হিউম্যান-সেন্ট্রিক ডিজাইন লজিককে সহানুভূতি এবং ঘর্ষণের (friction) মাধ্যমে আবৃত করে। এজেন্ট-রেডি ডিজাইন লজিককে স্পষ্ট এবং মেশিন-রিডেবল কন্ট্রাক্টের মাধ্যমে প্রকাশ করে। ইন্টারফেস আর পলিসি থাকে না; ম্যানিফেস্টই হয়ে ওঠে পলিসি।
এই পরিবর্তন মানুষের বিকল্প হওয়া নয়। এটি মূলত স্বীকার করা যে আপনার সফটওয়্যারে এখন একাধিক ধরণের কলার রয়েছে। প্রত্যেকের জন্যই সমান কঠোরতা প্রয়োজন।
আসল শিক্ষা
ক্লিকের জন্য ডিজাইন করা বন্ধ করুন। নিয়মের জন্য ডিজাইন করা শুরু করুন। যদি আপনার সিস্টেম ঘোষিত অ্যাকশন, প্রেক্ষাপট অনুযায়ী পারমিশন, কনসেন্ট চেক এবং শেয়ারড অডিট ট্রেইলের মাধ্যমে প্রতিটি কলারকে নিয়ন্ত্রণ করতে পারে, তবে অন্য প্রান্তে কে বা কী আছে তা কোনো বিষয় নয়। মানুষ বা এজেন্ট, সবাই একই গেটের মুখোমুখি হবে। আগে গেট তৈরি করুন। API হলো কেবল একটি দরজা। পলিসিই হলো সেই জিনিস যা ঘরটিকে সুরক্ষিত রাখে।