एजेंट Surfaces

एक surface वह तरीका है जिससे उपयोगकर्ता (या अन्य सिस्टम) आपके ऐप के साथ इंटरैक्ट करते हैं: एक चैट विंडो, एक डैशबोर्ड पेज, एक बैकग्राउंड जॉब, किसी अन्य एजेंट से एक API कॉल। Agent-Native आपको इन्हें बिना अपनी मूल लॉजिक को फिर से बनाए मिक्स और मैच करने देता है, क्योंकि हर surface एक ही अंतर्निहित actions चलाता है। यदि आप Agent-Native में नए हैं, तो पहले Key Concepts पढ़ें।

Surfaces एक-दूसरे से कैसे संबंधित हैं

चार मुख्य उत्पाद आकार सबसे इंटरैक्टिव से पूरी तरह headless तक एक स्पेक्ट्रम पर हैं। जो चीज़ उन्हें composable बनाती है वह यह है कि वे समान actions और SQL-backed app state साझा करते हैं। जिस surface को agent चाहिए, वहाँ framework agent loop का उपयोग करें। एक नई surface जोड़ने का मतलब यह नहीं है कि नीचे की चीज़ों को फिर से लिखना होगा — आप बस उसी operations तक पहुंचने का एक नया तरीका जोड़ रहे हैं।

एक शुरुआती बिंदु चुनें

Chat सबसे सामान्य प्रवेश बिंदु है। जब आउटपुट समृद्ध होता है तो ऐप्स आमतौर पर इनलाइन UI बढ़ाते हैं, फिर जब उपयोगकर्ताओं को ब्राउज़ और शेयर करने के लिए स्थायी ऑब्जेक्ट की आवश्यकता होती है तो पूर्ण ऐप पेज जोड़ते हैं। वही actions बाद में आने वाले बटन, शेड्यूल की गई jobs, और बाहरी agents को शक्ति देते हैं। Embedded sidecar का उपयोग तब करें जब किसी ऐसे product में एजेंट जोड़ना हो जो आपके पास पहले से है, या बिना ब्राउज़र के चलने वाले काम के लिए Automation-first का उपयोग करें। यहाँ पूरी तस्वीर है:

Agent-Native पर Rich chat

बिल्ट-इन chat का उपयोग तब करें जब उपयोगकर्ता को एजेंट से बात करनी हो, tool calls देखनी हों, काम approve करना हो, native results inspect करने हों, और एक टिकाऊ thread history रखनी हो।

एक पूर्ण ऐप शुरुआती बिंदु के लिए, Chat template का उपयोग करें:

npx --yes @agent-native/core@latest create my-chat-app --template chat

सबसे सरल full-page chat:

import { AgentChatSurface } from "@agent-native/toolkit/app/chat";

export default function ChatRoute() {
  return <AgentChatSurface mode="page" className="h-screen" />;
}

जब किसी ऐप में full-page chat tab और AgentSidebar दोनों हों, तो दोनों surfaces पर एक ही storageKey का उपयोग करें, chatViewTransition सक्षम करें, और layout में chat-home handoff helpers इंस्टॉल करें। chat पेज से बाहर के सामान्य in-app links तब full chat को sidebar में morph कर सकते हैं जबकि active thread बनाए रखते हैं:

import { AgentChatSurface, AgentSidebar } from "@agent-native/toolkit/app/chat";
import {
  useAgentChatHomeHandoff,
  useAgentChatHomeHandoffLinks,
} from "@agent-native/core/client/agent-chat";
import { useLocation } from "react-router";

function ChatRoute() {
  return (
    <AgentChatSurface mode="page" storageKey="my-app" chatViewTransition />
  );
}

function AppLayout({ children }: { children: React.ReactNode }) {
  const location = useLocation();
  const handoffActive = useAgentChatHomeHandoff({
    storageKey: "my-app",
    activePath: location.pathname,
    enabled: location.pathname !== "/chat",
  });
  useAgentChatHomeHandoffLinks({ storageKey: "my-app", chatPath: "/chat" });

  return (
    <AgentSidebar
      storageKey="my-app"
      chatViewTransition
      openOnChatRunning={handoffActive}
    >
      {children}
    </AgentSidebar>
  );
}

अपने chrome के साथ सबसे सरल embedded chat:

import { AssistantChat } from "@agent-native/toolkit/app/chat";

export function ProjectChat({ threadId }: { threadId: string }) {
  return <AssistantChat threadId={threadId} />;
}

Actions स्पष्ट native widget results वापस कर सकते हैं ताकि chat आउटपुट केवल टेक्स्ट न हो। Tables, charts, और typed product cards iframes के बिना chat में first-party React components के रूप में रेंडर होते हैं। Native Chat UI देखें। जब एजेंट को पूर्वनिर्धारित React widget के बजाय arbitrary generated controls की आवश्यकता हो, तो Generative UI का उपयोग करें: यह sandboxed Alpine/Tailwind UI इनलाइन रेंडर करता है, app state और slot context पढ़ सकता है, और चुने गए values को chat में वापस भेज सकता है।

अनुरोध-स्कोप वाली action surfaces

जब चुने गए Agent या thread को केवल server द्वारा अधिकृत native actions का subset दिखाना हो, तब resolveActionSurface का उपयोग करें। callback हर interactive chat request पर prepareRequest के बाद चलता है। लौटाए गए नाम एक सख्त allowlist बनाते हैं: छोड़े गए actions provider schemas, execution registry, Plan mode preload और tool-search खोज में उपलब्ध नहीं होते।

createAgentChatPlugin({
  actions,
  nativeActionsInDev: true,
  resolveActionSurface: async ({ threadId, availableActionNames }) => ({
    allowedActionNames: await loadAllowedActions(
      threadId,
      availableActionNames,
    ),
  }),
});

यदि वही resolver बिना प्रतिबंध वाले default chat को भी संभालता है, तो { mode: "default" } लौटाएँ। इससे पहली model request में सभी उपलब्ध schemas लोड करने के बजाय सामान्य initialToolNames filtering और tool-search discovery बनी रहती है। यह स्पष्ट mode durable continuations में भी सुरक्षित रहता है।

खाली सूची कोई native action उपलब्ध नहीं कराती। अज्ञात नाम access बढ़ाने के बजाय request को fail करते हैं। सभी अनुमत actions पहली model request पर सीधे लोड होते हैं; पहले से अधिकृत catalog में खोज चाहिए तभी tool-search को साफ़ तौर पर शामिल करें। callback केवल interactive Agent chat को सीमित करता है, HTTP, MCP, A2A, jobs या triggers को नहीं। default framework guidance और शुरू किए गए sub-agents वही surface inherit करते हैं। trusted shell tools अपने-आप request-filtered sandbox तक सीमित हो जाते हैं, क्योंकि unrestricted shell सख्त action boundary लागू नहीं कर सकता।

अनुरोध-स्कोप वाले अतिरिक्त actions

जब कॉलर जिन actions का उपयोग कर सकता है वे केवल अनुरोध के समय पता चलते हों, जैसे सर्वर चलते समय उपयोगकर्ता द्वारा register किए गए tools, तब resolveAdditionalActions का उपयोग करें। callback हर authenticated interactive chat run (production और dev) के लिए एक बार चलता है, tool-search और resolveActionSurface से पहले, इसलिए दोनों को लौटाई गई entries दिखती हैं। ये केवल उसी run के लिए उस कॉलर की registry में जुड़ती हैं। A2A tasks और MCP ask_app calls इन्हें तभी पाते हैं जब आप उन surfaces को additionalActionSurfaces में सूचीबद्ध करें; surface callback को बताता है कि कौन-सा अनुरोध कर रहा है।

createAgentChatPlugin({
  actions,
  additionalActionSurfaces: ["a2a"],
  resolveAdditionalActions: async ({ surface, ownerEmail, orgId }) =>
    loadUserTools(ownerEmail, orgId, {
      includeEditorTools: surface === "chat",
    }),
});

लौटाई गई entries को untrusted input मानें। framework किसी entry को अनदेखा कर देता है, और एक बार warning log करता है, जब उसका नाम 1–64 अक्षरों, अंकों, _ या - का न हो; जब वह नाम किसी template, framework, dev या MCP action का हो, उन actions सहित जो agent से छिपे हैं; जब वह ऐसा mcp__ नाम हो जिसे कॉलर नहीं देख सकता; या जब उसकी tool definition उपयोग योग्य न हो। descriptions से छिपे control characters हटा दिए जाते हैं और उनकी लंबाई सीमित की जाती है। parameters सादे JSON data का एक सीमित schema होना चाहिए जिसकी root object हो, और जो केवल सामान्य validation और annotation keywords का उपयोग करे। अज्ञात keywords, pattern, patternProperties, uniqueItems, $async, $id, anchors, और recursive अथवा schema के बाहर इंगित करने वाला कोई भी $ref अस्वीकार कर दिया जाता है। model को schema की जाँची हुई copy दिखती है, और जिस call के arguments उसके विरुद्ध validate करने के लिए बहुत बड़े हों, वह अस्वीकार कर दी जाती है। readOnly और access जैसे flags आपके ऐप की अपनी घोषणाएँ हैं, जिन पर framework वैसे ही भरोसा करता है जैसे run पर: इन्हें इस आधार पर set करें कि आपका code क्या करता है, किसी उपयोगकर्ता द्वारा register किए गए metadata से कभी नहीं।

हर entry उस कॉलर से बंधी होती है जिसके लिए उसे resolve किया गया था। हर call, चाहे कोई भी dispatcher उसे करे, किसी दूसरे उपयोगकर्ता या organization के लिए चलने से इनकार करता है, entry की access policy लागू करता है, और arguments को उसके schema के विरुद्ध type coercion के बिना validate करता है।

नाम केवल तब pin होते हैं जब कोई hosted chat turn durable background run के रूप में जारी रहता है। callback फिर चलता है, और turn इन entries और कॉलर के MCP tools दोनों के लिए अपने मूल नाम बनाए रखता है: नई entries बाहर रहती हैं, जो नाम गायब हो गया वह call करने पर error लौटाता है, और जो नाम बना रहता है वह अपनी वर्तमान definition चलाता है। बाकी हर request नए सिरे से resolve होती है, जिसमें local sidecar पर हर continuation भी शामिल है, और जो टूटा हुआ stream अपने run से फिर जुड़ता है वह कुछ भी resolve नहीं करता।

binding की पहचान नाम में रखें, जैसे कोई window id या scope (notes_window_42_insert), ताकि rebind ऐसा पढ़ा जाए कि एक tool जा रहा है और दूसरा आ रहा है। "हमेशा अनुमति दें" approvals tool के नाम का अनुसरण करते हैं, इसलिए जब वही नाम बाद में किसी नई चीज़ का अर्थ लेता है तब भी वे लागू रहते हैं।

इसे रोकने के लिए entry पर revision सेट करें: एक-बार की approvals और "हमेशा अनुमति दें" उस revision को दर्ज करते हैं जिसके लिए वे दी गई थीं, और अलग revision होने पर उपयोगकर्ता से फिर पूछा जाता है। कस्टम "हमेशा अनुमति दें" handler को approval का askId set-tool-approval-policy को approvalId के रूप में पास करना चाहिए; इसके बिना, यह अनुमति केवल उन entries पर लागू होती है जिनमें कोई revision नहीं है।

जिस tool का conversation ने पहले उपयोग किया था या उसे load किया था, लेकिन जो इस run के पास अब नहीं है, उसे call करने पर Unknown tool की जगह Error: Tool no longer available के साथ विफलता मिलती है, और load किए गए tools के गायब होने के बाद शुरू होने वाला run model को बताता है कि कौन-से गायब हुए। अगर उपयोगकर्ता ने उस call को स्वीकृत किया था, तो run रुक जाता है, model को उसके बिना आगे बढ़ने नहीं देता। chat के लिए callback को threadId, requestedTurnId और internalContinuation भी मिलते हैं, ताकि जो ऐप पूरे turn के लिए एक ही tool set चाहता है, वह अपना snapshot रख सके।

ये entries केवल agent loop के लिए native tools हैं। कॉलर के MCP tools की तरह, इन तक run-code या tool-orchestration से नहीं पहुँचा जा सकता।

event chat और a2a के लिए सेट होता है; ask_app calls में यह नहीं होता। anonymous अनुरोधों, scheduled jobs, automations या agent-team sub-agents के लिए callback नहीं बुलाया जाता। callback द्वारा throw की गई error अनुरोध को विफल कर देती है।

Native inline UI

इसका उपयोग तब करें जब आपके actions structured data वापस करते हैं — records की एक list, एक chart dataset, एक status summary — जो plain text विवरण के बजाय chat thread के अंदर एक वास्तविक UI component के रूप में रेंडर होनी चाहिए। आप action पर एक chatUI renderer परिभाषित करते हैं, और Agent-Native इसे एक first-party React component के रूप में रेंडर करता है: कोई iframes नहीं, कोई अलग rendering path नहीं।

यह सही विकल्प है जब आउटपुट का एक स्पष्ट, reusable आकार हो जिसे आप एक बार डिज़ाइन करेंगे और कई agent responses में उपयोग करेंगे। उन controls के लिए जिन्हें एजेंट को runtime पर dynamically बनाने की आवश्यकता है, इसके बजाय Generated inline UI देखें।

पूर्ण renderer API, widget library, और BYO agent runtime integration के लिए Native Chat UI देखें।

Generated inline UI

इसका उपयोग तब करें जब एजेंट को ऐसा control बनाना हो जो अभी तक pre-built widget के रूप में मौजूद नहीं है — एक custom form, वर्तमान context के आधार पर बना picker, एक बार का calculator। native widgets के विपरीत, generated UI को एजेंट runtime पर Alpine.js और Tailwind से compose करता है, iframe में sandboxed चलता है, और चुने गए values को chat thread में वापस भेज सकता है।

Generated UI transient (एक बार रेंडर होकर हटाई गई) या एक reusable extension के रूप में saved हो सकती है जो उपयोगकर्ता के लिए persist करती है।

पूर्ण API, sandbox constraints, और extension persistence model के लिए Generative UI देखें।

Full application

full app path का उपयोग तब करें जब उपयोगकर्ताओं को टिकाऊ objects और workflows की आवश्यकता हो: forms, dashboards, calendars, inboxes, editors, documents, assets, या reports।

Full apps उसी action और agent contract के चारों ओर product UI जोड़ते हैं:

Chat template से शुरू करें जब आप अपने actions के चारों ओर एक minimal app चाहते हों, या किसी domain template से जब आप एक complete product shape चाहते हों।

Full-page Manage Agent

हर Agent-Native ऐप को अंततः एक ऐसी जगह की आवश्यकता होती है जहाँ उपयोगकर्ता अपने एजेंट को configure कर सकें: standing instructions सेट करना, क्या हुआ है यह review करना, MCP servers connect करना, automations manage करना, और access control करना। उस UI को scratch से बनाना बहुत काम है। Agent-Native एक pre-built full-page component, AgentTabsPage, ship करता है जो बारह tabs में यह सब cover करता है।

फ़र्स्ट-पार्टी टेम्पलेट इसे mount नहीं करते: Settings वही सब कवर करती है (Agent › Model, Instructions, Memory, Skills, Files और Sub-agents, साथ ही ऐप के Automations और MCP server पेज), /agent Settings पर रीडायरेक्ट करता है, और AgentSidebar पर agentPageHref="/settings/agent" Settings › Agent › Model खोलता है। जब किसी ऐप को पूरी agent सतह एक पेज पर चाहिए, तो AgentTabsPage को उसके अपने route पर mount करें।

import { AgentTabsPage } from "@agent-native/toolkit/app/agent-page";
export default function AgentRoute() {
  return <AgentTabsPage />;
}

साझा पेज वर्तमान में दो groups में बारह tabs प्रदान करता है:

पेज केवल personal (user-scope) data दिखाता है। आज कोई org-level toggle नहीं है। यह मौजूदा components और access checks पर एक thin shell है, कोई नया admin console नहीं: Connections बताता है कि ऐप क्या call कर सकता है; MCP बताता है कि बाहरी clients इससे कैसे connect होते हैं।

अभी तक शामिल नहीं:

• Organization-scoped view
• Grants और scope editing
• Revocation UI
• Per-iteration provenance history

Embedded sidecar

Embedded sidecar का उपयोग तब करें जब मुख्य product पहले से मौजूद हो और आप उसके साथ एजेंट चाहते हों।

Server plugin आपके host app में Agent-Native routes mount करता है और host identity server-side resolve करता है:

import { createAgentNativeEmbeddedPlugin } from "@agent-native/core/server";

export default createAgentNativeEmbeddedPlugin({
  databaseUrl: process.env.AGENT_NATIVE_DATABASE_URL,
  auth: getHostSession,
  actions: hostActions,
});

React sidecar page context और host commands पास करता है:

import { AgentNativeEmbedded } from "@agent-native/core/client/host";
export function AppShell({ children }) {
  return (
    <AgentNativeEmbedded
      getContext={() => ({
        route: { pathname: window.location.pathname },
        selection: { text: window.getSelection()?.toString() || undefined },
      })}
      onNavigate={(payload) =>
        router.navigate((payload as { path: string }).path)
      }
      onRefresh={() => queryClient.invalidateQueries()}
    >
      {children}
    </AgentNativeEmbedded>
  );
}

यह कैसे connect होता है

दो टुकड़े एक bridge के रूप में काम करते हैं: host app page context (current route, selected text, focused object) को AgentNativeEmbedded में पास करता है, और एजेंट onNavigate और onRefresh के माध्यम से commands वापस भेजता है। Server plugin identity handle करता है — यह host session को resolve करता है ताकि एजेंट एक अलग login के बिना सही उपयोगकर्ता के रूप में कार्य करे। Host app में कुछ भी बदलने की आवश्यकता नहीं है; plugin Agent-Native के routes को आपके मौजूदा routes के साथ attach करता है।

Host auth, database isolation, iframe/picker mode, और lower-level bridge APIs के लिए Embedding SDK देखें।

Automation-first app

Automation-first path का उपयोग तब करें जब काम चलते समय किसी को custom browser screen की आवश्यकता न हो: scheduled jobs, integrations, backend workflows, CLI loops, दूसरा एजेंट, या कोई मौजूदा product जो Agent-Native को call करता हो।

यह वह आकार है जो तब उपयोग करना चाहिए जब automation product surface हो। आप terminal, Slack, email, scheduled job, दूसरे एजेंट, या Chat से एक request भेजते हैं ("मेरे unread emails summarize करो," "Slack पर daily metrics post करो," "पिछले हफ्ते reply करने वाले candidates ढूंढो") और एजेंट कार्य करता है और परिणाम जहाँ वह होना चाहिए वहाँ वापस करता है। यह अभी भी एक वास्तविक ऐप है, कोई stateless prompt नहीं: actions, auth sessions, app state, thread/run history, settings, credentials, और share records सभी SQL में रहते हैं।

इस pattern को तब चुनें जब:

• काम background में होता है। अधिकांश value तब बनाई जाती है जब उपयोगकर्ता नहीं देख रहा: triage agents, daily-report agents, on-call responders।
• आउटपुट ऐप से बाहर जाता है। एजेंट Slack पर post करता है, email भेजता है, या third-party system अपडेट करता है; ऐप में browse करने के लिए कुछ नहीं है।
• Domain one-shot है। Research bot, summary generator, report writer जिसमें कोई persistent object नहीं है जिसे list view की आवश्यकता हो।
• आप एक automation prototype कर रहे हैं। अभी operation ship करें; जब उपयोगकर्ताओं को inspect और steer करने की आवश्यकता हो तो chat या app pages जोड़ें।

यदि आपका product persistent objects के चारों ओर बना है जिन्हें उपयोगकर्ता browse, pivot, और share करते हैं (emails, events, documents, charts), तो इसके बजाय full application या template चुनें; वे पूर्ण UI plus एजेंट जोड़ते हैं।

बॉक्स में क्या आता है

एक automation-first ऐप dashboard काम छोड़ देता है, और यह day one से channel-agnostic है। वही एजेंट web, Slack, Telegram, email, और अन्य agents से चलता है क्योंकि सब कुछ उन्हीं actions के माध्यम से जाता है। trade-off यह है कि कोई "सब कुछ एक नज़र में" view नहीं है; यदि उपयोगकर्ताओं को इसकी आवश्यकता है, तो Chat से शुरू करें या एक छोटा status page या list view जोड़ें।

जब आप built-in Chat shell जोड़ते हैं, तो framework पाँच management surfaces प्रदान करता है जिन्हें आपको बनाना नहीं है: Chat (मुख्य input), Resources (skills, memory, instructions, sub-agents, और connected MCP servers), Automations, Thread history, और Settings। वे आमतौर पर पर्याप्त हैं: इससे बात करें, देखें क्या हुआ है, configure करें यह कैसे behave करता है। Chat के लिए पहुंचें जब आप वह browser UI जोड़ने के लिए तैयार हों, या Slack/Telegram, scheduled jobs, और shared secrets के साथ workspace-style शुरुआती बिंदु के लिए Dispatch template के लिए।

सबसे छोटा no-browser local path एक scaffold plus एक action है:

npx --yes @agent-native/core@latest create my-agent --headless
cd my-agent
pnpm install

फिर टिकाऊ operation परिभाषित करें:

import { defineAction } from "@agent-native/core/action";
import { z } from "zod";

// One action powers every app surface: UI, agent, HTTP, MCP, A2A, and CLI.
export default defineAction({
  description: "Summarize this week's submissions.",
  readOnly: true,
  schema: z.object({ formId: z.string() }),
  run: async ({ formId }) => {
    return { formId, summary: "34 submissions, up 18% from last week." };
  },
});

एक action को इस प्रकार call किया जा सकता है:

• HTTP: POST /_agent-native/actions/summarize-week
• CLI: pnpm action summarize-week --formId form_123
• App-agent CLI: pnpm agent "Summarize form_123"
• MCP: Claude, ChatGPT, Codex, Cursor, OpenCode, Copilot, और अन्य MCP hosts से
• A2A: किसी अन्य agent-native app या agent peer से
• UI: useActionQuery, useActionMutation, या callAction के माध्यम से
• Agent tool: built-in chat loop से

यह no-database या stateless mode नहीं है। App-agent loop SQL में sessions, threads, runs, settings, credentials, application state, और share records store करता है। Local development defaults PGlite पर; hosted automation-first apps को persistent PostgreSQL database का उपयोग करना चाहिए।

यदि आपको project folder से पूरे agent loop को headlessly चलाने की आवश्यकता है, तो उपयोग करें:

pnpm agent "Summarize this week's forms."

यदि किसी अन्य ऐप या script को पूरे एजेंट को call करने की आवश्यकता है, तो agentNative.invoke("analytics", "...") या agent-native invoke CLI का उपयोग करें। यह cross-app काम को A2A path पर रखता है जबकि local काम actions पर रहता है।

Workers, jobs, integration webhooks, और custom hosts server API के माध्यम से agent loop को सीधे drive कर सकते हैं। यह actions से lower-level है — आप engine, model, messages, tools, actions, एक event sink, और एक abort signal खुद प्रदान करते हैं:

import { runAgentLoop } from "@agent-native/core/server";

await runAgentLoop({
  engine,
  model,
  systemPrompt,
  tools,
  actions,
  messages,
  send,
  signal,
});

अधिकांश apps के लिए, scheduled prompts और integration webhooks पहले से ही इस loop को आपके लिए call करते हैं। इसे सीधे तभी उपयोग करें जब custom no-browser host, eval runner, या server-side orchestration surface बना रहे हों। पूर्ण signature के लिए Server: Production agent handler देखें।

एक folder के विरुद्ध चलाना

यदि आपका लक्ष्य "इस folder के विरुद्ध एजेंट चलाना" है, तो उस folder में app-agent loop से शुरू करें: automation-first app scaffold करें, actions/instructions जोड़ें, pnpm agent "..." चलाएं। यह काम को उसी action/runtime/state contract के अंदर रखता है जो ऐप production में उपयोग करेगा।

External coding harnesses एक अलग product surface हैं जो Claude Code, Codex, Pi, Cursor, Mastra, या इसी तरह के runtimes को Agent-Native ऐप के अंदर embed करने के लिए हैं। इनका उपयोग तब करें जब आप coding-agent product बना रहे हों, न कि local agent-native workflow शुरू करने के default तरीके के रूप में।

Cloud repo access

Cloud automation-first apps के लिए जिन्हें repository access की आवश्यकता है, GitHub connector plus token CRUD model का उपयोग करें: repositories list करना, files search करना, files read करना, files create या edit करना, files delete करना, और provider-scoped credentials के माध्यम से access revoke करना। Local development में, target repository को explicitly set करें:

GITHUB_REPOSITORY=owner/repo pnpm agent "Read README.md and suggest the next action."

VM clone या long-lived sandbox checkout को primary cloud repo-access model के रूप में treat न करें। Sandboxes isolated code execution के लिए अभी भी महत्वपूर्ण हैं, लेकिन repository access connector layer के माध्यम से explicit, permissioned, auditable, और revocable होनी चाहिए।

Sessions और runs share करना

Automation-first sessions और runs टिकाऊ objects हैं। Shareability को phased होना चाहिए: पहले read/share links, ताकि teammates sanitized prompts, outputs, और run status inspect कर सकें; बाद में permissioned writable collaboration, ताकि run continue करना, actions approve करना, schedules edit करना, या configuration बदलना explicit access checks के माध्यम से जाए।

अपने एजेंट पर Rich chat

इस path का उपयोग तब करें जब आपका एजेंट किसी अन्य framework या runtime के साथ पहले से बना हो और आप उसके चारों ओर Agent-Native का chat UI चाहते हों। AgentChatRuntime boundary है: आपका runtime normalized events stream करता है, और Agent-Native composer, transcript, tool calls, approvals, native widgets, और app layout render करता है।

import { AssistantChat } from "@agent-native/toolkit/app/chat";
import { createHttpAgentChatRuntime } from "@agent-native/core/client/agent-chat";

const runtime = createHttpAgentChatRuntime({
  endpoint: "/api/support-agent/chat",
});

export function SupportAgentChat() {
  return <AssistantChat runtime={runtime} threadId="support" />;
}

OpenAI Agents, OpenAI Responses, Claude Agent SDK, Vercel AI SDK, और AG-UI के लिए ready-made runtime helpers मौजूद हैं, plus किसी भी अन्य एजेंट (Mastra, Flue, Eve, LangGraph, या custom service) के लिए ऊपर normalized HTTP runtime। ACP end-user app chat या A2A transport नहीं है, और Agent-Native वर्तमान में A2UI support का दावा नहीं करता। ACP एक specific जगह में support किया जाता है: harness layer के माध्यम से local coding agent (Gemini CLI, Claude Code, ...) को drive करना, यहाँ chat runtime के रूप में नहीं।

Native Chat UI: BYO agent runtimes event shapes, runtime helpers, और chatUI tool-result metadata का canonical home है। External एजेंट को chat में wire करते समय वहाँ से शुरू करें।

आगे क्या है