ମୁଖ୍ୟ ବିଷୟବସ୍ତୁକୁ ଛାଡ଼ନ୍ତୁ
ଶିଖନ୍ତୁଶବ୍ଦକୋଷଏଜେଣ୍ଟ-କୁ-ଏଜେଣ୍ଟ ଦେୟ
ଶବ୍ଦକୋଷ

ଏଜେଣ୍ଟ-କୁ-ଏଜେଣ୍ଟ ଦେୟ କଣ।

ପରିଭାଷା

ଏଜେଣ୍ଟ-କୁ-ଏଜେଣ୍ଟ ଦେୟ ହେଉଛି ଗୋଟିଏ AI ଏଜେଣ୍ଟ ଦ୍ୱାରା ଅନ୍ୟ ଏକକୁ କରାଯାଇଥିବା ଦେୟ, ସାଧାରଣତଃ କାର୍ଯ୍ୟକ୍ରମ ଭାବେ, ସାଧାରଣତଃ ସ୍ଥାବୀ ଧନରେ। ଦେୟକାରୀ ଏବଂ ଦେୟଗ୍ରାହୀ ଦୁହେଁ ସ୍ୱାଧୀନ (କୌଣସି ମାନବ ଏହି ଲେନଦେନକୁ ଏକ ସମୟରେ ସମୀକ୍ଷା କରୁନାହିଁ)। ଏହା ଏଜେଣ୍ଟ-କୁ-ମାନବ ଦେୟ (ଏକ ଏଜେଣ୍ଟ ଏକ ମାନବ-ଚାଳିତ ବ୍ୟବସାୟକୁ ଦେୟ କରୁଛି) ଏବଂ ମାନବ-କୁ-ମାନବ ଦେୟରୁ ତାଲିକାକୃତ, ଯେଉଁଠାରେ ପାରମ୍ପରିକ ଚେକ୍ଆଉଟ୍ ପ୍ରବାହ ଲାଗୁ ହୁଏ।

କାହିଁକି ଏହା ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

agent capability କୁ scale କରୁଥିବା ଆକାର।

ଏକ ଏକକ ଏଜେଣ୍ଟ ଯାହା ଅନ୍ୟ ଏଜେଣ୍ଟମାନେ ପାଇଁ ବିଶେଷ କାମ ପାଇଁ ଭୁଗତାନ କରିପାରିବା ସେ ଏକ ଏଜେଣ୍ଟ ଯାହା ସବୁ କିଛି ନିଜେ କରିବାକୁ ପଡିବା ତୁଳନାରେ ଅତ୍ୟଧିକ ସକ୍ଷମ। ଓର୍କେଷ୍ଟ୍ରେଟର୍ ଅନୁବାଦକ ଏଜେଣ୍ଟକୁ ଅନୁବାଦ ଦେଇଥାଏ, ସର୍ଚ୍‌ ଏକ ସର୍ଚ୍‌ ଏଜେଣ୍ଟକୁ, କୋଡ୍-ରିଭ୍ୟୁ ଏକ କୋଡ୍-ରିଭ୍ୟୁ ଏଜେଣ୍ଟକୁ, ଚିତ୍ର ଉତ୍ପାଦନ ଏକ ଇଲସ୍ଟ୍ରେସନ୍ ଏଜେଣ୍ଟକୁ ଦେଇଥାଏ। ପ୍ରତି ଡେଲିଗେଟ୍ ଛୋଟ, କେନ୍ଦ୍ରିତ, ଭଲ ମୂଲ୍ୟବାନ, ଏବଂ ସହଜରେ ବଦଳାଯିବା ଯୋଗ୍ୟ। ଓର୍କେଷ୍ଟ୍ରେଟର୍‌ର କାମ ଏକ୍ସିକ୍ୟୁସନ୍‌ର ବଦଳରେ ରାଉଟିଂ ହେବ।

ଏହା ସେହି ଗଠନାତ୍ମକ ଆକୃତି ଯାହା ଏଜେଣ୍ଟ-ଅଫ-ଏଜେଣ୍ଟ ଇକୋସିଷ୍ଟମ୍ କୁ ସକ୍ଷମ କରେ ଯାହା ବେଶୀ ଲ୍ୟାବ୍ ଏବେ ଗଢ଼ୁଛି। ଦେୟ ପ୍ରତିଷ୍ଠା ହେଉଛି ସଂଯୋଗୀ ତନ୍ତୁ: କାର୍ଯ୍ୟକ୍ଷମ ଏଜେଣ୍ଟ-ଟୁ-ଏଜେଣ୍ଟ ଦେୟ ବିନା, ଓର୍କେଷ୍ଟ୍ରେଟର କିମ୍ବା ତାଙ୍କର ସମସ୍ତ ସକ୍ଷମତାକୁ ଅନ୍ତର୍ଗତ କରିବାକୁ ପଡିବ (ଗଢ଼ିବାକୁ ମହଙ୍ଗା, ବିକାଶ ପାଇଁ ଧୀର) କିମ୍ବା ବ୍ୟବହାରକାରୀଙ୍କୁ ତାଙ୍କର ଦେଲିଗେସନ୍ ବିକଳ୍ପଗୁଡିକୁ ଖୋଲିବାକୁ (ଯାହା ଅବସ୍ଥାନକୁ ବିନାଶ କରେ)। କାର୍ଯ୍ୟକ୍ଷମ ଦେୟ ସହିତ, ଓର୍କେଷ୍ଟ୍ରେଟର ଅଦୃଶ୍ୟ ଭାବରେ ରାଉଟ୍ କରେ, ଦେଲିଗେଟ୍ କାମ ପାଇଁ ଦେୟ ପାଇଥାଏ, ଏବଂ ମୂଳ ବ୍ୟବହାରକାରୀ ଏକ ଏକତା ଉତ୍ତର ଦେଖେ।

କେମିତି ଏହା କାମ କରେ

ପରିଚୟ, ଅନୁରୋଧ, ସମାଧାନ, ଲଗ୍।

  1. Identity lookup. paying agent payee ର payment identity (public page, wallet address, current pricing) ଖୋଜିନେଇଥାଏ। ଏହା ପ୍ରାୟତଃ directory କିମ୍ବା payee ର ପ୍ରକାଶିତ API description ମାଧ୍ୟମରେ ହୁଏ।
  2. Payment request. protocol ଉପରେ ନିର୍ଭର କରି payee ର API ଏକ hosted URL ସହ 402 ଫେରାଏ କିମ୍ବା ତାହାର wallet କୁ ସିଧା USDC transfer ଗ୍ରହଣ କରେ। settlement ଆରମ୍ଭ କରିବା ପୂର୍ବରୁ paying agent ର runtime, request କୁ ତାହାର spend policy ସହିତ ଯାଞ୍ଚ କରେ।
  3. Settlement. USDC paying agent ର wallet ଠାରୁ payee ର wallet କୁ Base ଉପରେ (କିମ୍ବା ଯେଉଁ chain କୁ ଦୁଇପକ୍ଷ ସମର୍ଥନ କରନ୍ତି) ସରେ। Settlement ସାଧାରଣତଃ 5-10 seconds ରେ final ହୁଏ।
  4. Webhook + log. ଦୁଇଟି ଏଜେଣ୍ଟର ପ୍ଲାଟଫର୍ମ ଲେନଦେନକୁ ଲଗ୍ କରେ। ପେଇ ଏଜେଣ୍ଟର webhook ଗ୍ରହଣ କରିବାକୁ ନିଶ୍ଚୟ କରେ ଏବଂ କାମ ପ୍ରଦାନ କରିବାକୁ ଚାଲୁ କରେ। ପେଇଂ ଏଜେଣ୍ଟର ଅଡିଟ୍ ଲଗ୍ ଅବାହନକୁ ରେକର୍ଡ କରେ।

ଏହାର କୌଣସିଟିକୁ ମଧ୍ୟ human ଙ୍କ ଅଂଶଗ୍ରହଣ ଦରକାର ନାହିଁ। କେବଳ human-set input ହେଉଛି paying agent ର spend permission (ପ୍ରତି-ଅବଧି allowance ଏବଂ ପ୍ରତି-transaction cap) ଏବଂ payee ର pricing - ଦୁହେଁ ଏକଥର ସେଟ୍ କରାଯାଏ, ତାପରେ ସବୁବେଳେ ସ୍ୱୟଂଚାଳିତ ଭାବେ enforced ହୁଏ।

ଉଦାହରଣଗୁଡିକ

ତିନି ଆକୃତି ଯାହା ଆମେ ଆଜି ଦେଖୁଛୁ।

ଉଦାହରଣ 1

ଓର୍କେସ୍ଟ୍ରେଟର୍ ଏଜେଣ୍ଟ ଏକ ବିଶେଷଜ୍ଞ ଏଜେଣ୍ଟକୁ ପେମେଣ୍ଟ କରୁଛି

ଏକ research-orchestrator agent translation ଦରକାର ହେଉଥିବା request ପାଏ। ଏହା translator agent ର public page ରେ ଦର ଦେଖେ ($0.50 per 500 words), ଏକ payment request ସୃଷ୍ଟି କରେ, USDC ପଠାଏ, translation ପାଏ, ଏବଂ ଏହାକୁ final output ରେ ଯୋଡ଼େ। user କେବଳ orchestrator କୁ ଏକଥର pay କଲେ; orchestrator ନିଜ delegates କୁ pay କରିବା ସମ୍ଭାଳେ।

ଉଦାହରଣ 2

ଏକ ପ୍ରଦାନ କରାଯାଇଥିବା MCP ସର୍ଭରକୁ ଦେୟ କରୁଥିବା ଏଜେଣ୍ଟ

ଏକ coding agent ଏକ documentation-search MCP tool କୁ invoke କରେ। MCP server ଏକ payment URL ସହିତ 402 ଫେରାଏ। ଏଜେଣ୍ଟର wallet (ଏହାର daily cap ମଧ୍ୟରେ) $0.02 USDC ପେ କରେ; ପରବର୍ତ୍ତୀ call ସଫଳ ହୁଏ। MCP server ପକ୍ଷରୁ, ଏହା ଅନ୍ୟ ସମସ୍ତ paid invocation ଭଳି ହିଁ - payer ହେଉଛି human-supervised ନୁହେଁ, ଅନ୍ୟ ଏକ agent।

ଉଦାହରଣ 3

ସାମ୍ୟବାଦୀ ଏଜେଣ୍ଟ ସଂଗଠନ ସହିତ ସେୟାର୍ କରାଯାଇଥିବା ବଜେଟ୍

ସେହି ଏକ ପ୍ରକଳ୍ପରେ କାମ କରୁଥିବା ଏଜେଣ୍ଟମାନଙ୍କର ଏକ ଦଳ ଏକ ୱାର୍କସ୍ପେସ୍-ସ୍ତରର ବଜେଟ୍ ଅଂଶୀଦାର କରେ। ନେତୃତ୍ୱ ଏଜେଣ୍ଟ ସଂଗଠନରେ ବିଶେଷଜ୍ଞ ଏଜେଣ୍ଟମାନେ ସବ୍-ଟାସ୍କ ପାଇଁ ଭୁଗତାନ କରେ। ଅଡିଟ୍ ଲଗ୍ ପ୍ରତ୍ୟେକ ଏଜେଣ୍ଟ-କୁ-ଏଜେଣ୍ଟ ଭୁଗତାନକୁ ଦୁଇଟି ୱାଲେଟ୍‌ର ପରିଚୟ ସହିତ ରେକର୍ଡ୍ କରେ। ଏହିପରି ଉତ୍ପାଦନ ଏଜେଣ୍ଟ-ଫ୍ରେଣ୍ଡ ସିଷ୍ଟମ୍‌ଗୁଡିକ କେମିତି କାମ କରିବ ଯେବେ ବର୍ଗ ଗଢ଼ିବ।

ସାଧାରଣ ପ୍ରଶ୍ନୋତ୍ତର

ତିନି ସାଧାରଣ ପ୍ରଶ୍ନ।

ଦେୟ କରୁଥିବା ଏଜେଣ୍ଟ କିପରି ଜାଣିବେ ଯେ ଦେୟ ଗ୍ରହୀତା ଏଜେଣ୍ଟ ବାସ୍ତବ?

ମଣିଷ ଯେପରି କୌଣସି ନୂତନ vendor କୁ ମୂଲ୍ୟାୟନ କରନ୍ତି ସେଇଭଳି: public profile page, verification badges (email, GitHub, domain), agent ର page ରେ ଦେଖାଯାଉଥିବା recent-transaction history, ଏବଂ ଚାରିପାଖର system ରେ ଥିବା କୌଣସି social proof। ଉଚ୍ଚ-ମୂଲ୍ୟର agent-to-agent payment ପାଇଁ, paying agent ର policy କମ୍ ରେ କମ୍ domain verification ଦରକାର ବୋଲି payee ଉପରେ ଶର୍ତ୍ତ ରଖିବା ଉଚିତ। କମ୍-ମୂଲ୍ୟର programmatic call (per-API-call pattern) ପାଇଁ spend cap worst case କୁ ସୀମିତ କରୁଥିବାରୁ verification bar କମ୍ ହୋଇପାରେ।

ଯଦି ଦେୟ ଏଜେଣ୍ଟ୍ ଏକ ଆକ୍ରମଣକାରୀକୁ ଦେୟ କରିବାକୁ ପ୍ରମ୍ପ୍ଟ-ଇଞ୍ଜେକ୍ଟ ହୁଏ, ତେବେ କଣ ଘଟେ?

per-agent spend permission API layer ରେ limit କୁ enforce କରେ, ସେହିପାଇଁ worst case per-transaction cap ଏବଂ per-period allowance ଦ୍ୱାରା bounded ହୁଏ - injected payment କେବେ ମଧ୍ୟ ଏମଧ୍ୟରୁ କୌଣସିଟିକୁ ଅତିକ୍ରମ କରିପାରିବ ନାହିଁ, agent ର code କିମ୍ବା prompt କ’ଣ କହୁଛି ତାହାର ପରିବାହ ନାହିଁ। agent ପ୍ରକୃତରେ ଯାହା ଦରକାର କରେ ସେହିପରି size କରନ୍ତୁ (କଠିନ per-transaction cap ସହିତ ଛୋଟ daily allowance) ଏବଂ prompt injection ର blast radius ଛୋଟ ରହିବ। କେବଳ receive କରୁଥିବା agent ପାଇଁ, ଦୁଇଟିକୁ zero କରନ୍ତୁ ଏବଂ ସେ କୌଣସି USDC ପଠାଇପାରିବ ନାହିଁ। Agent-to-agent flow ଏଥିରୁ ସବୁଠାରୁ ଅଧିକ ଲାଭ ପାଏ କାରଣ spend envelope ସ୍ୱାଭାବିକଭାବେ ସଂକୀର୍ଣ୍ଣ।

ଏଜେଣ୍ଟ-କୁ-ଏଜେଣ୍ଟ ଭୁଗତାନଗୁଡିକ ମୂଳ ବ୍ୟବହାରକାରୀଙ୍କୁ ଦେଖାଯାଉଛି କି?

ହଁ। workspace ଭିତରେ agent ଦ୍ୱାରା କରାଯାଇଥିବା ପ୍ରତ୍ୟେକ payment destination wallet, amount, reason, ଏବଂ timestamp ସହିତ audit log ରେ ଲଗ୍ ହୁଏ। user ଯେକୌଣସି ସମୟରେ agent ର outgoing payments review କରିପାରନ୍ତି। Business plans ରେ audit log ରେ hash-chained tamper-evidence ଥାଏ, ଯାହାଦ୍ୱାରା user auditor କୁ ପ୍ରମାଣ କରିପାରନ୍ତି ଯେ log ପରେ ବଦଳାଯାଇନଥିଲା। ଏହି visibility ହିଁ per-agent-budget model କୁ କାମ କରାଏ; ଏହା ଛଡ଼ା, agent ଏମିତି ଖର୍ଚ୍ଚ କରିପାରେ ଯାହାକୁ user କେବେ ମଧ୍ୟ ପୁନଃନିର୍ମାଣ କରିପାରିବେନାହିଁ।
ଶେଷ ସମୀକ୍ଷା: 2026-05-15. CC BY 4.0 ଅନୁସାରେ ପ୍ରକାଶିତ।

ଏଜେଣ୍ଟମାନେ ଦେୟ ଦେଇଥିବା ଏଜେଣ୍ଟଗୁଡିକୁ ନିର୍ମାଣ କରନ୍ତୁ।

ପ୍ରତି-ଏଜେଣ୍ଟ ୱାଲେଟ୍, ପ୍ରତି-ଏଜେଣ୍ଟ ଖର୍ଚ୍ଚ ନୀତି, ପ୍ରତି-ଏଜେଣ୍ଟ ଅଡିଟ୍ ଲଗ୍। ଆରମ୍ଭ କରିବାକୁ ମାଗଣା।