দুটা category এতিয়া যথেষ্ট নহয়
বছৰ বছৰ ধৰি traffic দুটা bucket-ত ভাগ কৰা হৈছিল: human আৰু bot। Human-এ product পায়। Bot-এ block, rate-limit, বা ignore কৰা হয়।
এই ভাগ এতিয়া আৰু খাটে নে। কিছুমান automated visitor হৈছে agent, যিয়ে real customer-ৰ হৈ কাম কৰে: এটা assistant-এ plan তুলনা কৰা, এটা agent-এ আপোনাৰ API-ৰ জৰিয়তে data টানি অনা, এটা tool-এ এটা task সম্পূৰ্ণ কৰিবলৈ আপোনাৰ MCP server-লৈ call কৰা। AI provider-এ এতিয়া এই ধৰণৰ user-initiated access নিজেই document কৰে: OpenAI-এ কয় যে তেওঁৰ ChatGPT-User agent-এ pages visit কৰে যেতিয়া user-এ ChatGPT-ক এটা question কৰে (OpenAI crawler documentation), আৰু Anthropic-এ একে উদ্দেশ্যৰ বাবে Claude-User তালিকাভুক্ত কৰে (Anthropic crawler documentation). একে সময়তে, কিছুমান person AI-ৰ সৈতে কাষে কাষে কাম কৰে, message draft কৰে, form পূৰণ কৰে আৰু assistant কাষত লৈ product navigate কৰে। এই সকলোবোৰক human বা bot-লৈ ঠেলি দিলে দুয়োফালে বেয়া সিদ্ধান্ত হয়। বৈধ agent-সমূহ block হয়, আৰু বাস্তৱ মানুহো challenge হয় কাৰণ তেওঁলোকৰ আচৰণ অস্বাভাৱিক যেন লাগে।
ভাল সিদ্ধান্তলৈ যোৱা ধৰণে মানৱ আৰু AI এজেণ্ট ট্রাফিক পৃথক কৰিবলৈ, আপোনাক অধিক category লাগে আৰু প্ৰতিটো result কিমান বিশ্বাসযোগ্য সেয়াও জানিব লাগিব। website traffic AI agents-ৰ পৰা আহে নেকি কেনেকৈ জানিব শীৰ্ষক blog post-এ এইটো সম্ভৱ কৰা signal-সমূহ walkthrough কৰে, আৰু SaaS apps use case-এ দেখুৱায় যে এই পাৰ্থক্যই product decision কেনেকৈ সলনি কৰে।
চাৰি class, প্ৰত্যেকৰে নিখুঁত অৰ্থ
Proof of Actor-এ interaction-সমূহক চাৰি class-ত classify কৰে। প্ৰত্যেকৰে এটা definition আৰু এটা স্পষ্ট সীমা আছে, যাতে আপোনাৰ team-ৰ ক'ৰবাই ফলাফলৰ অৰ্থ evidence-এ সমৰ্থন কৰা সীমাৰ বাহিৰলৈ টানি নাযায়। এই taxonomy-ৰ reasoning-ৰ বাবে Human, AI-assisted or agent: a taxonomy for app traffic পঢ়ক।
Human
supported observable signal-এ human-directed interaction সূচায়। এই class-এ interaction-টো ক'লে কোনে direction দিছে, identity-ৰ বিষয়ে নহয়। Human result-এ ব্যক্তিজন কোন সেয়া verify নকৰে, আৰু সৰ্বত্র AI ব্যৱহাৰ হোৱা নাছিল বুলিও দাবী নকৰে।
Human + AI
AI সহায় declared কৰা হৈছিল, বা supported integration-ৰ জৰিয়তে observe কৰা হৈছিল যি সত্যিই তাক দেখা পায়। উদাহৰণস্বৰূপ, user-এ আপোনাৰ own disclosure control-ৰ জৰিয়তে content-টোক AI-ৰে drafted বুলি চিহ্নিত কৰা, বা signed-in user-ৰ হৈ built-in assistant-এ এটা action সম্পন্ন কৰা বুলি আপোনাৰ application-এ report কৰা। অধিক জানিবলৈ AI-assisted interaction glossary entry চাওক।
Agent
Automated বা agent-origin interaction, যাক verifiable identity-এ সমৰ্থন কৰে, যেনে published key-ৰ পৰা valid request signature, বা সতর্কভাৱে qualified inference। Agent result-এ কোনে acting কৰি আছে তাক বৰ্ণনা কৰে। ই এইটো বুজোৱা নাই যে agent-টো authorized, safe, বা person-ৰ valid delegation-ৰ সৈতে কাম কৰি আছে। autonomous agents বিষয়ে অধিক পঢ়ক।
Unknown
available evidence-এ reliable determination সমৰ্থন নকৰে। Unknown এটা সৎ আৰু উপযোগী result: ই দেখুৱায় আপোনাৰ coverage ক'ত শেষ হয়, আৰু ই আপোনাৰ policy-সমূহক অস্পষ্ট case-সমূহ deliberate-ভাৱে সামলাবলৈ দিয়ে, accident-ৰ জৰিয়তে নহয়।
প্ৰতিটো class-ৰ সৈতে এটা basis থাকে
মানৱ আৰু agent traffic পৃথক কৰা কামৰ আধা অংশহে। আনটো আধা হৈছে প্ৰতিটো conclusion কিমান শক্তিশালী সেয়া জনা। সেইকাৰণে প্ৰতিটো Proof of Actor result-এ এটা basis বহন কৰে:
- Verified: এটা পৰীক্ষাযোগ্য assertion validate কৰা হৈছে, উদাহৰণস্বৰূপ published key-ৰ বিপৰীতে checked কৰা request signature।
- Declared: client বা আপোনাৰ application-এ সেয়া কৈছে, উদাহৰণস্বৰূপ agent-এ নিজকে নামকৰণ কৰা বা user-এ AI সহায়ক disclosure কৰা।
- Inferred: behavioral বা contextual signal-ৰ পৰা টনা conclusion, যাক সদায় inference বুলি label কৰা হয়।
- Unknown: determination-ৰ বাবে যথেষ্ট evidence নাই।
Class আৰু basis-ৰ সংমিশ্ৰণেই আপোনাক নিখুঁত rule গঢ়িবলৈ দিয়ে। verified agent আৰু inferred agent দুয়ো agent, কিন্তু আপুনি প্ৰথমটোক structured API দিবলৈ আৰু দ্বিতীয়টোক standard rate limit-ৰে সামলাবলৈ বিচাৰিব পাৰে। declared AI-assisted submission আৰু human session দুয়ো normal-ভাৱে আগবাঢ়িব পাৰে, এটা label-সহ যি আপোনাৰ support team-ক সহায় কৰে। সম্পূৰ্ণ taxonomy আপুনি Detection & Limitations-ত পাব।
classification কেনেকৈ হয়
Proof of Actor-এ প্ৰতিটো interaction-ৰ বাবে একেই evidence-first path অনুসৰণ কৰে। সম্পূৰ্ণ ব্যাখ্যা How It Works-ত আছে।
আপোনাৰ integration-এ যি signal দেখা পায়
- Request signature automated client-ৰ পৰা যিয়ে নিজৰ key প্ৰকাশ কৰে, RFC 9421-ত সংজ্ঞায়িত HTTP Message Signatures ব্যৱহাৰ কৰি। IETF Web Bot Auth working group-ৰ charter হৈছে এই পদ্ধতিত automated client-এ কেনেকৈ authenticate কৰে তাক standardize কৰা।
- Declaration client-ৰ পৰা যিয়ে নিজকে চিনাক্ত কৰে, যেনে AI crawler আৰু fetcher-ৰ documented user agent, আৰু আপোনাৰ own application-ৰ পৰা যেতিয়া সেয়াই AI সহায়ক জড়িত আছে বুলি জানে।
- Request context server-side integration-এ উপলব্ধ, যেনে header আৰু protocol detail।
- Interaction signal approved browser integration-ৰ পৰা, যি pages-ত চলি আছে তাত।
signal-ৰ পৰা result-লৈ
Signal-সমূহ পৰীক্ষা কৰা হয়, basis অনুসৰি label দিয়া হয় আৰু সংযোগ কৰা হয়। শক্তিশালী verified evidence-এ নিশ্চিত result দিয়ে। দুর্বল বা বিপৰীত evidence-এ qualified inference বা Unknown দিয়ে। timeout বা missing signal কেতিয়াও Human result নহয়। output হৈছে এটা class, এটা basis আৰু এটা evidence summary, যি আপোনাৰ team-ৰ যিকোনো ব্যক্তিয়ে পঢ়িব পাৰে।
traffic পৃথক হোৱাৰ পাছত আপুনি কি কৰিব পাৰে
Proof of Actor তিনিটা capability-ৰ ওপৰত সংগঠিত: Detect, Understand আৰু Route।
প্ৰতিটো interaction-ৰ পিছে থকা actor detect কৰক
প্ৰতিটো context-ত উপলব্ধ signal সংগ্ৰহ কৰক আৰু verified assertion-সমূহ inference-ৰ পৰা পৃথক কৰক। Unknown দৃশ্যমান ৰাখক।
প্ৰতিটো actor-এ আপোনাৰ product কেনেকৈ ব্যৱহাৰ কৰে বুজি লওক
route অনুসৰি আৰু সময়ৰ সৈতে human, AI-assisted, agent আৰু unknown activity-ৰ mix চাওক। যিকোনো result খুলি known আৰু not known কি সেয়া চাওক। agent-সমূহ ক'ত concentrate কৰে আৰু AI সহায় common হোৱা workflow-সমূহ চিনাক্ত কৰক।
প্ৰতিটো actor-ক সঠিক experience-লৈ route কৰক
evidence-এ সেয়া সমৰ্থন কৰিলে আপোনাৰ own policy প্ৰয়োগ কৰক। public website-ত websites use case-এ দেখুৱায় এই choice-সমূহ বাস্তৱ route-লৈ কেনেকৈ map কৰে:
- verified agent-লৈ human-shaped page-ৰ পৰিৱৰ্তে structured response বা API serve কৰক।
- human-directed session-ৰ বাবে standard experience ৰাখক।
- AI-assisted submission label কৰক যাতে সঠিক team-এ সেয়া handle কৰে।
- sensitive action-ৰ বাবে আপোনাৰ own condition-এ দাবী কৰিলে অধিক শক্তিশালী credential বিচাৰক।
- প্ৰতিটো route-ত Unknown-ৰ বাবে এটা explicit fallback বাছক, যেনে public page allow কৰা আৰু account change-ত existing check বজাই ৰখা।
rolling out actor-aware policies safely-ৰ guide-এ observation-ৰ পৰা enforcement-লৈ এটা route-এ একেলগে কেনেকৈ যাব সেয়া cover কৰে।
এইটো আপোনাৰ user-ৰ বাবে কিয় গুৰুত্বপূর্ণ
এইটো সঠিককৈ কৰিলে আপোনাৰ application ব্যৱহাৰ কৰা সকলোৰে লাভ হয়।
মানুহে অধিক মসৃণ experience পায় কাৰণ তেওঁলোকক অস্পষ্ট score-ৰ জোৰত challenge কৰা নহয়। AI-ৰ সৈতে কাম কৰা মানুহে workflow-ত disclosed assistance-ৰ বাবে support পায় য'ত সেয়া মানায়। বৈধ agent-সমূহে নিজৰ কাম কৰিবলৈ বিশ্বাসযোগ্য, structured পদ্ধতি পায়, যিয়ে scraping আৰু আপোনাৰ interface-ৰ ওপৰত load কমায়। আপোনাৰ team-এ explainable decision পায়, সেয়ে support conversation, incident review আৰু policy change-সমূহ guesswork-ৰ পৰিৱৰ্তে evidence-ৰ ওপৰত থিয় হয়।
login-টোৱে actor নহয়
বিভ্ৰান্তিৰ অন্যতম common উৎস হৈছে account নিজেই। signed-in session-এ আপোনাক কোন account ব্যৱহাৰ হৈ আছে সেয়া কয়। ই current interaction কোনে direction দিছে সেয়া নকয়। একেই account-টো পুৱা তাৰ owner-এ settings-ৰ মাজেৰে click কৰি, দুপৰীয়া owner-এ report export কৰিবলৈ কোৱা assistant-এ, আৰু সন্ধিয়া API key-ৰ জৰিয়তে কাম কৰা agent-এ ব্যৱহাৰ কৰিব পাৰে।
এই তিনিটাক একে ভাবে ধৰিলে দুয়োফালে সমস্যা হয়। যদি account-ৰ প্ৰতিটো request owner-ৰ বুলি ধৰা হয়, agent-এ person-ৰ বাবে ডিজাইন কৰা workflow-লৈ যাব পাৰে। যদি প্ৰতিটো অস্বাভাৱিক request attack বুলি ধৰা হয়, owner-ৰ own tool block হয়। actor-ক account-ৰ পৰা পৃথক কৰিলে আপোনাৰ application-এ authentication আৰু authorization যি আছে সেয়া ঠিক তেনেদৰে ৰাখিব পাৰে, আৰু এতিয়া কোন acting কৰি আছে তাৰ missing context যোগ কৰিব পাৰে। সেই context-ই structured access offer কৰা সম্ভৱ কৰে, human-only workflow-ত entry নোখোলা।
observation mode-ত আৰম্ভ কৰক
প্ৰতিটো deployment observation mode-ত আৰম্ভ হয়। Proof of Actor-এ ফলাফল record কৰে, আনহাতে আপোনাৰ application-এ আগৰ দৰে একেবাৰে response দিয়ে। আপোনাৰ team-এ human, AI-assisted, agent আৰু unknown activity-ৰ baseline গঢ়ে, ইতিমধ্যে জনা outcome-ৰ সৈতে তুলনা কৰে, আৰু এটা rule সলনি হোৱাৰ আগতে যিকোনো false positive review কৰে। policy সাজু হ'লে, আপুনি সেয়া এটা workflow-ৰ বাবে enable কৰে আৰু তাৰ পৰা বিস্তাৰ কৰে।
founding developer program-ত যোগদান কৰক
Proof of Actor সীমিত application team-ৰ সৈতে private beta-ত আছে। নিৰ্বাচিত founding developer-এ agreement-ত নিৰ্ধাৰিত usage limit-ৰ ভিতৰত up to 12 months free access পাব পাৰে, হাতে-কামে feedback-ৰ বিনিময়ত। আপুনি আমাৰ engineer-ৰ পৰা direct integration support, capability-লৈ early access, আৰু priority-ত প্ৰভাৱ পায়।
আপোনাৰ application-ত যদি মানৱ আৰু AI এজেণ্ট ট্রাফিক পৃথক কৰিব লাগে, early access-ৰ বাবে আবেদন কৰক আৰু আপোনাৰ বাবে আটাইতকৈ বেছি বুজিব বিচৰা interaction-টোৰ বিষয়ে আমাক কওক।
Proof of Actor অন্বেষণ কৰক, how it works পঢ়ক, বা ঠিককৈ evidence-এ কি স্থাপন কৰিব পাৰে সেয়া চাওক।
Source
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Overview of OpenAI crawlers, OpenAI.
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.