Last published on: 7 October 2026 at 15:21 UTC
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Open Agent Registry, Inc.
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Corporation
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
Delaware
Provide the website URL of the applying entity, if available.
https://agentcommunity.org
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
false
Choose Yes or No.
false
1
Provide the primary business phone number without including the country code.
(845) 910-1065
Provide the primary business email address of the applying entity.
contact@agentcommunity.org
Enter the street address (no PO Box).
8 The Green #23482
Enter the city, village, municipality, etc.
Dover
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Delaware
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
19901
US
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Balazs Nemethi
Balazs Nemethi
Balazs Nemethi, Esther Dyson
Balazs Nemethi
Agent Community Foundation, Balazs Nemethi, Esther Dyson
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
agent
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
A person or thing that acts on behalf of another. In current internet usage, an autonomous software program acting on behalf of an identified principal.
If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)
Latin
Provide a representation of the string according to the International Phonetic Alphabet.
/ˈeɪ.dʒənt/
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
The mission of .agent is trust: a home on the internet for the Agent Community, where holding a name means a verified operator stands behind and for the agent, and anyone dealing with that agent can check it. The namespace gives agents names worth trusting, and it gives the community that builds them a shared, findable place, run as neutral ground on equal, published terms. When an agent books, negotiates, or transacts on a person's or organization's behalf, the question that matters is who is answerable for what it just did. A .agent name answers it: every active domain name is bound to an identified, verified principal who has accepted responsibility for the agents operating under it. Verification does not make the principal's identity public. The intended registrants are members of the Agent Community, defined in Q132 and stated here in its complete form: "The Agent Community is the worldwide community of engineers, researchers, organizations, builders, and operators who develop, research, deploy, or take responsibility for the operation of autonomous software agents that act on behalf of an identified principal." A .agent name resolves only for a registrant who is a member of the Agent Community and who completes identity verification, executes the Registrant Accountability Undertaking, and demonstrates control of the agents and agent-facing service endpoints operating under the domain name. The registrant must also publish and maintain a discovery record for the name: a public record, findable from the name itself, of which agents operate under it and that a verified registrant answers for them. The registration policy in Q151 states these conditions as binding contract language and will be incorporated as Specification 12 of the .agent Registry Agreement. The intended users are wider than the registrants. Any person, organization, or agent dealing with a .agent name can rely on one fact: the name resolves only while its holder is verified and accountable. Activities already carried out toward this purpose. The community has operated continuously since January 2025. The applying entity runs the membership register, the public member directory and map, and the community's Discord server. It maintains the community's public events calendar, and it publishes a blog and Agent Brief, the community's weekday newsletter. It authored an open specification for discovering agents through DNS and placed it on the IETF (Internet Engineering Task Force) public record as an Internet-Draft on 16 March 2026, filed with Open Agent Registry, Inc. as the stated affiliation; the discovery-record requirement in Q151 builds on this kind of mechanism and does not depend on any single specification. Activities to be carried out. The applying entity will operate eligibility verification and the activation gate described in Q151 and Q155, publish the verification process and expected timeframes, and maintain the challenge and appeals procedure under the published registration policy. Registration policy will be directed by the Agent Community Foundation (the 'Foundation') under the commitments in Q172 to Q175. Why the purpose is sustainable. The accountability problem the TLD answers does not depend on any product cycle: it exists wherever software acts on a principal's behalf, whatever protocols and platforms are current. The Specification 12 policies fix what must not change: who is tested, what happens on failure, and that the standards, periods, and procedures must be published. The verification criteria are set by the technical specification the Foundation adopts, and can change with the field. Registry operations are to be funded from registration revenue. The successor-continuity commitment in Q173 keeps the community policies binding on any future operator, so the purpose survives a change of ownership.
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
The Agent Community: engineers, researchers, organizations, builders, and operators who develop, research, deploy, or take responsibility for the operation of autonomous software agents that act on behalf of an identified principal.
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
Category: an activity-based community that organizes online. The Agent Community is a worldwide community of people and organizations defined by a shared practice, not by a place, a language, or an industry sector. That practice is technical: its members develop, research, deploy, or take responsibility for the operation of autonomous software agents that act on behalf of an identified principal. Within that single practice, members occupy five overlapping roles: 1. Builders: engineers who develop autonomous agents and the frameworks that run them. 2. Researchers: academic and industrial researchers working on autonomous agent systems. 3. Operators: persons and organizations that deploy or operate agents on a principal's behalf and answer for their conduct. 4. Infrastructure and tooling providers: those building the identity, discovery, safety, and interoperability layer agents run on. 5. Standards and governance participants: those developing open specifications for agent discovery, authentication, and capability exchange. These roles overlap. A member may occupy more than one; they are perspectives on one practice, not sub-communities. The community's recorded member categories are two: individuals and organizations. Membership is open to individuals and organizations across all of these roles. Membership is recorded, not assumed. Registration is by name and requires accepting the community charter, in which the member states their engagement with this practice; the register records the acceptance and the date (see Q137). The community is worldwide, organized online around this shared practice rather than around a place, language, or affiliation. These are roles within one shared activity: building and operating autonomous agents that act on behalf of identified principals. What makes that activity one community rather than five occupations is a shared norm: someone stands behind and for each agent. The community exists to carry that norm, and the registration policy in Q151 makes it binding on those members who become registrants.
Describe and provide evidence of the relationship between the applying entity and the identified community.
The applying entity exists for this community and has operated it from the entity's first day. The community's organized existence began on 3 January 2025, started by Balazs Nemethi: its X account was created that day and its first public post was published the same day. Open Agent Registry, Inc. (the applying entity) was incorporated in Delaware on 29 July 2025, more than six months later. The practice of building and operating autonomous agents is older than this community and larger than any register. The Agent Community organizes that practice as a recorded body founded on 3 January 2025: a name and a recorded membership. Evidence of the relationship: 1. Members join through the community's own registration flow. The community's home, agentcommunity.org, carries the membership register, the join flow, the public member map, and the blog. 2. The applying entity administers the entire membership; its size and composition are stated in Q139. 3. It builds and maintains the member directory, which members can edit, maintains the community's public events calendar (see Q143), and runs an introduction agent that makes direct member-to-member introductions, building cohesion and partnerships between members. 4. It publishes Agent Brief, the community's weekday newsletter, and its blog. 5. It authored the community's open discovery specification (AID) and placed it on the IETF (Internet Engineering Task Force) public record as an Internet-Draft on 16 March 2026, filed with Open Agent Registry, Inc. as the stated affiliation.
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.
There is one organizing body: the applying entity, Open Agent Registry, Inc. It operates the community's infrastructure, administers the membership register, and runs the community's shared activities. How the organization works in practice: Membership and identity. Members register at agentcommunity.org as individuals or organizations and accept the community charter; acceptance is required to complete registration. The applying entity administers the register (see Q139). The public map and directory. The applying entity builds and maintains a public, linkable map of member organizations, presented in various segments, at agentcommunity.org/map. Members are encouraged to maintain their own profiles. Events. The community's public events calendar carried at least two listings in every month from September 2025 through July 2026 (see Q143). Publishing. Agent Brief, the community's weekday newsletter (163 issues from 29 November 2025 to 31 July 2026), and the community's blog (see Q141). Direct communication. The applying entity operates the community's Discord server for direct member-to-member communication. Introductions. The applying entity runs an introduction agent that makes direct member-to-member introductions, so that members learn about each other's work and form partnerships as the membership grows. Workstreams. Five member workstreams are forming, each with signed-up members and its own public mailing list and archive on the community site. Governance and leadership. Balazs Nemethi leads the applying entity. The Agent Community Foundation, a Delaware nonprofit organization, will direct registration policy for the .agent TLD under the commitments in Q172 to Q175, which are enforceable by ICANN Contractual Compliance, with the Public Interest Commitments Dispute Resolution Procedure (PICDRP) available to parties claiming harm. It does not administer the community, its membership, or its activities; the applying entity remains the community's only organizing body.
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
The community has a formal, recorded membership process. A person or organization becomes a member by registering on the community's website and creating a profile as an individual or an organization, the community's two recorded member categories (see Q139). Completing registration requires an applicant to accept the community charter and affirm their active engagement with autonomous software agents or related tooling; tooling is itself one of the community roles described in Q134. That recorded affirmation is what qualifies the applicant as a member. Membership is free. The community deliberately keeps joining open to everyone engaged with autonomous agents, from the engineer shipping an agent framework to the organization that takes responsibility for the operation of an agent its customers deal with. The practice exists independently of the applying entity, and anyone engaged in it may join. Registration records membership, so the register is where the community is counted. Two design facts: 1. Members are registered, not merely self-identified. Joining is a recorded step. The register distinguishes individuals from organizations, records the month of joining, and records charter acceptance. 2. Membership and eligibility to activate are different statuses by design. Participation in the community is broad, and membership is free and open. Eligibility to activate a .agent name is a policy status within the membership, held by members who complete identity verification, execute the Registrant Accountability Undertaking, and demonstrate control of their agents and endpoints, as stated in Q151. Membership keeps the community broad. The eligibility policy makes registrants accountable.
Provide the primary location of the community.
Global. The community operates predominantly online. Member organization profiles show 124 distinct countries.
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
Estimated size: 29,808 members at filing, counted from the register: 21,355 individuals and 8,453 organizations, with organization members across the 124 countries in Q138. Joining is free and requires accepting the community charter.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
The entire membership. Open Agent Registry, Inc. is the community's only organizing body and administers the register of all 29,808 members; every member joined through it (see Q135, Q137, Q139).
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
Yes. The engagement record since January 2025 is documented and dated, and it maps to the four practices named in this question. (a) Offering support. The applying entity builds and maintains the member directory as a service to members: member organizations have public profiles on the community's map at agentcommunity.org/map, grouped by the kind of agent work they do, and members can edit their own entries. It operates the join flow, membership support, and the community's Discord server, and it runs an introduction agent that makes direct member-to-member introductions, scaled to a membership of this size. (b) Sharing information. The applying entity publishes Agent Brief, the community's weekday newsletter (see Q136). Issues are public. The applying entity has also published 34 dated blog posts between 4 January 2025 and 23 July 2026. (c) Responding to specific community needs. The applying entity develops and publishes open technical work on agent discovery, answering a need its members raised: making an agent findable and attributable from a domain name. That work does not bind the Foundation, which may draw on it, outside work, or both when adopting the technical specification governing the registry. As membership grew from 2,000 to almost 30,000, the applying entity revised its plans for a larger community. Five member workstreams with public mailing lists are forming, Discord use is growing, and the introduction agent answers a need that growth itself created: at almost 30,000 members, it helps each member find the members most relevant to their work. (d) Fostering and strengthening relationships. The events program runs on the community's public events calendar, with at least two listings in every month from September 2025 through July 2026. Events include hackathons, summits, demo nights, and the SF kickoff on 26 June 2026, held in person and online. The introduction agent carries this beyond events, connecting members directly so that relationships form across the whole register.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
The applying entity runs them. It is the community's only organizing body: 1. Events: it maintains the community's public events calendar and organized or co-hosted community events. 2. Publications: it writes and publishes the blog and produces Agent Brief, the community's weekday newsletter. 3. Directory: it builds and maintains the member directory and public map; members can edit their entries. 4. Workstreams: it is forming five member workstreams. 5. Introductions: it runs an introduction agent that makes direct member-to-member introductions. 6. Standards work: it develops and publishes open technical work on agent discovery. That work does not bind the Foundation, which may draw on it, outside work, or both when adopting the technical specification governing the registry. 7. Community operations: it operates the membership register, join flow, and membership support; administers the community's Discord server and public social-media accounts; and maintains five workstream mailing lists with public archives.
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
Yes. The evidence here is interaction between members, dated and checkable. Members meet each other. The community's events program brings members together in person and online, at community-hosted and co-hosted events open to members and the wider public: 64 listings carrying 15,031 registrations, with at least two listings in every month from September 2025 through July 2026: hackathons, summits, and demo nights. The attached exhibit shows the community's events page (agentcommunity.org/events), its member map, and the question members answer about their own work. Members can see each other. The applying entity publishes the community's member map, "the periodic table of agents," presenting organization members in segments, so any member can see who else is in the community and where they sit in the field. Members also communicate directly on the community's Discord server. Members are introduced to each other. The applying entity runs an introduction agent that makes direct member-to-member introductions. It is built for a membership of this size: it exists so that members learn what other members are working on and can form partnerships from it, and it is being scaled as the register grows. Members act together on the community's shared undertaking, and they answer for themselves when they do. Endorsement letters are structured forms, not signature blocks alone. Organization and individual signers answer questions about themselves and their work in the field (see Q156). The responses are attributable, not anonymous: organization responses are bound to a named organization and signatory, and individual responses to named signers. Membership itself is deliberate, not a label applied from outside. Every member registered by name through the community's join flow, where acceptance of the community charter is required to complete registration. The membership spans distinct segments, and the register shows it: individuals and organizations, the community's two recorded member categories, occupying the overlapping roles described in Q134. Organizations register through a named person who is informed at signup that they are acting on behalf of the organization. The diversity is concrete. Member organizations include a nonprofit that convenes a long-running open-identity standards workshop, a major open-source artificial-intelligence platform, an accredited United States university, a national research institute recognized by the European Union, a national space research organization, a foundation stewarding a widely used open-source programming language, a federally qualified health center, a climate-journalism nonprofit, and a Fortune 250 utility. Individual members include a sitting European mayor who registered from an official municipal address.
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
Yes. The awareness is documented member by member. First, the endorsement record: 16,937 distinct members carry a signed letter endorsing this application. The signed letters are explicit, dated acts by members who knew of the application and chose to support it (see Q156). Second, the join paths. Members join through a public join flow. The join flow and the homepage state this application as a goal, and the community's blog has covered it since 2025. The applying entity has also stated its intention to apply through the community's public social-media accounts. Awareness is not confined to a core group. Members have joined in every month of the community's existence, and the endorsers are individuals and organizations from across the register. The awareness is corroborated from outside the community's own channels. Independent public reporting and commentary connected the community with this application before submission: Ruby AI News reported the community's ICANN application on 27 March 2026 (rubyai.beehiiv.com/p/ruby-ai-news-march-27th-2026) and Wes Roth posted public commentary on 25 March 2026 (see Q146); Justin Schroeder, Nagesh Nama, and Josh Lim each posted publicly about the .agent effort in March and April 2026 (see Q148 and its attached exhibit). Members' knowledge of the application did not depend on the applicant's own channels. The community exists in its own right. This application is one of the things it does rather than the reason it exists.
Provide evidence of the established presence of the community prior to the opening of the application submission period.
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
Yes. From 3 January 2025 through submission, outside individuals and organizations publicly identified the community or engaged with its work. (a) Media and public information. Ruby AI News (rubyai.beehiiv.com/p/ruby-ai-news-march-27th-2026) reported on 27 March 2026 that Agent Community was pursuing a community-led ICANN application for .agent. Outside public commentary also named the effort. On 25 March 2026, Wes Roth described it as a decentralized, community-driven initiative. On 15 June 2026, Turing Post discussed the .agent work and the agent community around it. These last two records are public commentary, not editorial reporting or endorsements. (b) Discussion in public forums. Outside DNS specialists engaged substantively with the community's Agent Identity and Discovery (AID) proposal. One opened a public issue on 2 March 2026 questioning its TXT-record design; another challenged its scaling assumptions on the public IETF DNSOP mailing list on 17 March. An individual presentation at IETF 125 on 19 March listed AID among existing related proposals. An approved DAWN Birds of a Feather (BoF) request, last updated 12 June, separately catalogued AID and linked agentcommunity.org among existing discovery efforts. These records show public technical awareness and discussion. The presentation and drafts are individual contributions, and approval of the BoF request is not IETF endorsement of AID, Agent Community, or .agent. (c) Programs and disclosed collaborations. Future in Review published a podcast on 24 April 2026 identifying its guest as founder of Agent Community, and its 18 June program listed Agent Community alongside other named institutions. Brave published a full podcast episode on 3 June identifying Balazs Nemethi as CEO of Agent Community. Brave is a disclosed member and supporter, so that episode shows collaboration and public visibility, not arm's-length coverage. ETHDenver published a talk with "Agent Community" in its title on its official channel on 21 February. These external program records show that producers publicly identified or presented Agent Community; claims made by the speaker remain attributable to the speaker. (d) Organization before the window. The community's organization, its charter, its events, its publications, and its membership all pre-date the window (see Q145). (e) Contributions to the wider field. The community's AID specification is open source, and its reference packages are published on public software registries. Separately authored research cites and evaluates it. A 25 March 2026 academic preprint gives AID its own comparison section and identifies it as the better fit for pure discovery. A 7 April Internet-Draft gives AID a numbered comparison section, and an Ericsson-authored survey of 3 July compares AID with other agent-discovery approaches. A separately maintained DNS discovery project identifies Agent Community and the .agent effort, with concurrent or later technical coordination disclosed. An outside operator also documented and published a live DNS record using the AID community specification by 10 June. Together, these dated records show outside awareness in public, technical, implementation, and program settings.
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
Yes. The pursuits are long-established in the field and continuous in the community. First, the pursuits are long-established in the field. The community's practice is building, studying, operating, and standardizing autonomous software agents that act on behalf of an identified principal. This practice goes back decades. The International Conference on Autonomous Agents and Multiagent Systems (AAMAS) held its 25th edition in 2026 under IFAAMAS, a standing nonprofit; its predecessor workshop series, Intelligent Agents/ATAL, began in 1994; and the field's journal, Autonomous Agents and Multi-Agent Systems, has published continuously from Volume 1 in 1998 to Volume 40 in 2026. The accountability problem the community organizes around, making an identified principal answerable for such software, does not expire with any product cycle; it exists for as long as such software is deployed. Second, the community's own activity is recurring and scheduled, with documented records. The events calendar carried at least two listings in every month from September 2025 through July 2026: eleven consecutive months of scheduled community activity. Agent Brief, the community's weekday newsletter, has published continuously since 29 November 2025 and is still publishing at submission, with 98 issues before the application window and 163 through 31 July 2026. The blog archive is public and dated (see Q141). The membership register records each member's joining month and shows signups in every month from January 2025 through August 2026: twenty consecutive months, a continuous record over the community's whole life that can be checked. The discovery specification is part of standards work: the outside IETF (Internet Engineering Task Force) Birds of a Feather (BOF) request of 26 September 2025, which lists the community's repository, and the community's AID Internet-Draft of 16 March 2026. Third, the activity continues past the filing date and does not depend on delegation of the TLD. Two further third-party-hosted events are already scheduled beyond the filing date, on 14 August and 8 September 2026. The community's operations are funded independently of the TLD: the financial plan filed with this application carries the community's programs, events, and standards work with their own budgets and income in every year of the projection, whether or not the TLD is delegated. Fourth, the community grows with the field it organizes. The field now carries professional credentials: IBM's RAG and agentic AI professional certificate was live by June 2025, and Cornell's agentic AI architecture certificate and Microsoft's AI agents professional certificate by November 2025 (coursera.org/professional-certificates/ibm-rag-and-agentic-ai; ecornell.cornell.edu/certificates/ai/agentic-ai-architecture; coursera.org/professional-certificates/microsoft-ai-agents). The applying entity adds programs and services as the membership grows: the introduction agent is being scaled, and the community's tooling is built around cohesion, member interaction, and a shared understanding of the field across the whole membership.
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.
Yes. The identified community is publicly known as Agent Community. The applied-for string, .agent, directly matches the distinguishing word in that name. This is the same community defined in Q132 as: "The Agent Community: engineers, researchers, organizations, builders, and operators who develop, research, deploy, or take responsibility for the operation of autonomous software agents that act on behalf of an identified principal." The community is therefore not a community of software agents. It is the organized community of people and organizations that build, research, deploy, and operate agents. Exact-name searches provide immediate public-name corroboration: searches for "Agent Community" return the organization and describe it as the community for agent builders. The attached evidence opens with signed-out results from three separate search indexes. Public use of the name is documented. A December 2025 event program co-organized by community member Hashgraph Online printed ".agent Community" as a panel affiliation, and ETHDenver published a February 2026 talk with Agent Community in its title. Before the application window, an outside publication, professional posts, organization statements, and independent public discussions used the name Agent Community, its public account, or agentcommunity.org in direct connection with the community-led application for .agent. Ruby AI News directly connected the named community with the community-led ICANN application for .agent. Nagesh Nama publicly identified agentcommunity.org and Agent Community while describing its community-governed purpose. Justin Schroeder, Josh Lim, Fact Protocol, and Gabriel Moncha each wrote in their own words about the same public .agent effort. Agentics Foundation recorded the Agent Community initiative and its .agent presentation in a public meeting recap; it is a collaborator, not a neutral observer. LSI Computer Systems and Civic publicly connected their participation or support with Agent Community and .agent; these statements are presented as participant or supporter evidence, not neutral coverage. Taken together, the record shows that Agent Community is the public name of the identified community and that .agent matches the distinguishing term in that name. The applicant does not claim that outsiders call the community "Agent," or claim exclusive ownership of the ordinary word "agent." The claim is that .agent matches the name by which this community is publicly identified.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
In an internet context, yes, and the claim is stated precisely. The claim. The established human senses of the word are commonly reached through a qualifier (a travel agent, a secret agent). In an internet context, the bare word already means software acting on a principal's behalf. The point is narrower: those senses are reached through their qualifiers, and the string applied for carries no qualifier. Usage by institutions and editors. The bare noun is the name the field's own institutions now use in public, dated, verifiable form; a capture set is provided as exhibits. OpenAI's product is "ChatGPT agent" (introduced 17 July 2025) and its developer kit is the "Agents SDK"; Microsoft operates an "Agent Store" (22 May 2025); Google's interoperability protocol is "Agent2Agent" (9 April 2025); Anthropic publishes a "Claude Agent SDK". The United States National Institute of Standards and Technology titled a 2025 publication "Tool Use in Agent Systems". News editors use the unqualified noun where the software sense is meant: the Associated Press reported that "a rogue agent hacked into a startup" (26 July 2026), The Guardian, Axios, and Semafor used the bare word for the same events that month, and Axios wrote "Agents will soon flood your channels" (25 February 2025). Academic venues do the same: 2025 workshop titles at NeurIPS, ICML, and AAAI use "agents" with no qualifier. The pattern the exhibits show is this: when the software sense is meant, the qualifier is increasingly omitted; when the other senses are meant, their qualifiers remain. Reference works. Cambridge added a COMPUTERS sense to the unqualified noun in 2026, defining an agent as "an artificial intelligence system that can operate in a complicated way without human control and is generally used for making decisions rather than creating content." Dictionary.com lists the artificial-intelligence sense of the related adjective "agentic" first, ahead of its person and process senses. Together, these entries show the software meaning operating in both the unqualified noun and its related adjective.
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator must not activate a .agent domain name in the DNS unless the registrant is a member of the Agent Community, as identified in this application, who has: (i) completed identity verification establishing the registrant as an identified legal or natural person; (ii) executed the Registrant Accountability Undertaking adopted by the Agent Community Foundation (the 'Foundation'), by which the registrant accepts responsibility, as principal, for the operation of the agents and agent-facing service endpoints operating under the registered domain name; and (iii) demonstrated, in accordance with the technical specification adopted by the Foundation, the registrant's control of those agents and endpoints.
Please see full instructions in AGB Q151.1.
Registry Operator must publish the eligibility verification process and the expected timeframes for its completion.
Please see full instructions in AGB Q151.1.
Registry Operator must require a registrant to demonstrate continued eligibility on any challenge filed under the challenge procedure in the registration policy published for the TLD, and in any other circumstances set out in the registration policy published for the TLD. Registry Operator must suspend resolution of any domain name whose registrant has failed to demonstrate continued eligibility within the period specified in that registration policy, and must maintain the suspension until eligibility is re-established. Registry Operator must require each registrant to publish and maintain a discovery record for each of the registrant's registered domain names. A discovery record is a public record, findable from the domain name itself, that identifies the agents and agent-facing service endpoints operating under the name and confirms that the registrant has accepted accountability for their operation under the Registrant Accountability Undertaking. The record must comply, in form, content and location, with the technical specification adopted by the Foundation. Registry Operator must suspend resolution of any domain name whose discovery record is not published or not maintained in accordance with that specification, on expiry of the cure period specified in the registration policy published for the TLD, and must maintain the suspension until the record is restored. Registry Operator must suspend resolution of any domain name whose registrant is found, under that challenge procedure or on Registry Operator's own review, to have ceased to satisfy the eligibility requirements of this policy, subject to any cure period specified in that registration policy.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator must require, as part of eligibility verification and before a domain name is activated, that the registrant affirm that the domain name corresponds to a personal name, company or juristic name, trade name, trademark, or the name of an agent operated by the registrant, and that the registrant or that agent is or will be publicly identified by that name.
Please see full instructions in AGB Q152.1.
Registry Operator must maintain a published procedure by which the accuracy of a registrant's name affirmation may be challenged by a third party or reviewed by Registry Operator, and must suspend resolution of any domain name whose affirmation has been found inaccurate under that procedure. An affirmation is inaccurate where it was untrue when made or has ceased to be true, and in any further circumstances set out in the registration policy published for the TLD.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator must require that eligibility, which attaches to the registrant, be established afresh on any change of registrant or change of control of the registrant. Where eligibility has been established in advance of the change, Registry Operator must not interrupt resolution; where it has not, Registry Operator must suspend resolution on expiry of the cure period specified in the registration policy published for the TLD, unless eligibility has by then been established.
Please see full instructions in AGB Q153.1.
Registry Operator must ensure that the registration policy published for the TLD states a challenge and appeals procedure with response timelines, available to registrants and to third parties challenging a registrant's eligibility or name affirmation, and states the cure periods applicable under these policies, and that each version of that policy is published with its effective date.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
The policies limit activation to members of the Agent Community, as identified in this application, who accept accountability for the agents operating under their domain names. A name may be registered through any accredited registrar before verification is complete, but every registration is subject to the eligibility requirement: the name does not resolve until that requirement is satisfied, a registrant who ceases to satisfy it is suspended, and a third party may challenge a registrant's eligibility under the challenge procedure in the registration policy published for the TLD. That limitation is the TLD's purpose, not a restriction on it: the namespace exists so that a party dealing with an autonomous agent can establish that an identified, verified principal has accepted responsibility for it and can be reached. Eligibility is deliberately narrower than membership: every registrant must be a member, but not every member will register a name. Membership counts the community; eligibility binds the registrants. Verification establishes an identified legal or natural person; it does not require publication of the registrant's identity, and registration data is handled under ICANN policy and applicable data protection law. The name-selection rule limits domain names to names by which the registrant or the registrant's agent is or will be publicly identified: the name is the anchor that attributes an agent to its principal. The affirmation is taken at verification, with proof required only on challenge. The change-of-control rule requires eligibility to be established again when the registrant changes or comes under new control: whoever controls an agent must have accepted accountability for it in its own name. Pre-cleared transferees see no interruption; otherwise the published cure period applies; the rule gates resolution, not transfer. In plain terms: the discovery record is how accountability attaches to the agent at the point where the agent is reached. It is a public record, findable from the domain name, saying which agents and endpoints operate under the name and that a verified registrant answers for them. The Foundation's technical specification sets the form and location, so the requirement does not depend on any one technology. The remaining limitations are delegations to the Foundation: the text of the Registrant Accountability Undertaking, the technical specification adopted by the Foundation, and the registration policy published for the TLD. Reserved names sit in the registration policy published for the TLD, outside these contract policies; there, withheld names are released by governance decision, not by default. These delegations put the content of those documents in the Foundation's hands rather than the operator's. The community's governance decides the policy content; the contract fixes who is tested, what happens on failure, and that the standards, periods, and procedures must be published; the registration policy published for the TLD carries the challenge and appeals procedure.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
Not duplicative. No requirement of applicable law, the Base Registry Agreement, or ICANN Consensus or Temporary Policy requires registrant eligibility verification, an accountability undertaking, or a published discovery record in this TLD; the policies add obligations that exist nowhere else. Reserved names are handled under the registration policy for the TLD, whose initial version is uploaded with this application and which does not restate the country and territory name reservations that Specification 5 of the Base RA already imposes. The baseline abuse obligations of the Base RA are inherited and are not repeated in these policies. Not contrary. The change-of-control policy gates resolution, not transfer: it adds no ground for denying an inter-registrar transfer and so does not conflict with the Transfer Policy's closed list of denial grounds. All policies operate within the Registry Operator's existing contractual controls over resolution. Nor are the policies contrary to applicable law: verification and suspension mechanics of this kind operate today in existing restricted TLDs, and registration data handling follows ICANN policy and data protection law. The governance commitment proposed separately (Q173) is expressly subordinated to the Registry Operator's obligations to ICANN and to applicable law. Compatible with ICANN's Bylaws. Each proposed policy turns on registrant status, established from binary, verifiable facts: identity verification completed or not; the Registrant Accountability Undertaking executed or not; control of the agents and endpoints demonstrated or not; the discovery record published and current or not; the name affirmation made or not, with an unresolved adverse finding or not. No provision conditions any of them on what an agent does or says, or on the content of any registrant's services or speech. Nothing in the policies asks ICANN to evaluate or regulate content, and ICANN Contractual Compliance can test every obligation from objective records. Additional Registry Service. The eligibility gate operates through standard EPP statuses: a domain name that has not completed verification is placed on serverHold and does not resolve, and the same status implements suspension. Eligibility verification itself is performed by or on behalf of the applying entity outside the registry system; the registry system only applies or lifts the status. The applying entity's assessment is therefore that no additional Registry Service is required, because only standard registry statuses and ordinary provisioning operations are used. If any element were determined to be an additional Registry Service, it would be submitted under the Registry Services Evaluation Policy.
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
From the community itself, documented member by member. At filing the register held 29,808 registered members: 21,355 individuals and 8,453 organizations (see Q139). Of these, 16,937 have executed a signed letter endorsing this application: 4,770 organizations and 12,167 individuals. Together, these endorsers constitute 56.8% of the register, including a majority of both organizations and individuals. Each letter was executed individually by the member concerned. Endorsement was open to every member through the community's own services. Signing was optional and unpaid. Each signed letter states the reasons for support. Every letter is addressed to the Community Priority Evaluation Panel and endorses this .AGENT community application. Some of the endorsing organizations are Brave Software, Grab, Hugging Face, the IIW Foundation, The Mifos Initiative, NEAR AI, The PHP Foundation, Product Hunt, Replit, Socket, Telnyx, Tiger Data and Upstage. Each was signed by a named representative of the organization from the organization's own domain. The attached exhibit reproduces an endorsement letter and lists endorsing organizations. The support is member-level because the applying entity is itself the organizing body (Q136). It comes in two forms: 4,770 organizations endorsed in their own name, and 12,167 individual members endorsed in their own name. The applying entity's stewardship of the registry is bounded. It will be required to operate .agent registration policy in accordance with the instructions of the Agent Community Foundation, a nonprofit with no ownership relationship to the applying entity (Q136). That commitment is proposed for inclusion in the Registry Agreement; once included, it is enforceable by ICANN Contractual Compliance (Q173 to Q175).
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
No. The applying entity is aware of no opposition to the applying entity, the application, or the applied-for string. No objection, opposition letter, statement of opposition, or demand concerning this application has been received. The endorsement letter quoted below addresses opposition directly: 6. Support and opposition statement We actively support this community application for .AGENT. We oppose the allocation of the .AGENT string to any applicant whose governance model would permit exclusive commercial control of the namespace, as this would undermine the open, interoperable character of agent technology infrastructure. The commitments in Q172 to Q175 are how this applicant is held, by binding contract, to the standard its endorsers set.
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
Yes
1. Draft the Registry Voluntary Commitment (RVC) as proposed contract language. Policies that are approved by ICANN will be included in Specification 11 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 11, Section 2 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed RVC in each response field. Up to 10 RVCs can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 3. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 5. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Registry Voluntary Commitment. For example: a) Registry Operator shall develop and implement a Registry Voluntary Commitment and publish this commitment on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the commitment described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 6. If the Registry Voluntary Commitment is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the commitment will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 7. See Section 7.8.3.3 Registry Commitments Evaluation Criteria for evaluation criteria that ICANN will apply for evaluating each proposed RVC.
Registry Operator must operate the TLD in accordance with the instructions of the Agent Community Foundation (the 'Foundation'), with respect to registration policy, save where such instructions would conflict with Registry Operator's obligations to ICANN or applicable law, in which case those obligations control.
Please see full instructions in AGB Q173.1.
Registry Operator must not assign the Registry Agreement without the prior written approval of the Agent Community Foundation, and must ensure that any successor assumes the Community Registration Policies and the governance commitments in full. This commitment does not apply to any assignment, transition or delegation of the TLD required or effected by ICANN under the Registry Agreement, including on expiry or termination.
1. If you are proposing any limitation to a proposed RVC in Question 173, please provide a rationale in this response field. See Section 7.8.3.3 Registry Commitments Evaluation Criteria. 2. If you are not proposing any limitation to a proposed RVC in Question 173, please type ""Not Applicable"" in this response field.
Three limitations are proposed, each with a specific rationale. First, the governance commitment yields where the Foundation's instructions would conflict with the Registry Operator's obligations to ICANN or with applicable law. An unqualified obligation to follow a third party's instructions could put the Registry Operator in breach through another's act. The carve-out fixes the order of precedence, so the commitment can be enforced. The commitment binds whenever the Foundation's instructions are compatible with the Registry Operator's ICANN obligations. Second, the governance commitment is scoped to registration policy. The Foundation directs who may hold and use names and on what conditions; it does not direct registry operations, security, or the Registry Operator's performance of its ICANN obligations. The scope keeps the commitment objective and measurable: whether a registration-policy instruction was issued and whether it was implemented are both verifiable facts. Third, the successor-continuity commitment does not apply where ICANN requires or effects a transition of the TLD. The Registry Operator cannot commit to block an action ICANN is entitled to take. Both tests are binary: an assignment is either required or effected by ICANN or it is not, and an assignment by the Registry Operator either carries the Foundation's prior written approval or it does not.
1. Provide background information to explain why the commitment is relevant, important, and necessary in support of the gTLD application. See Section 7.8.3.2.1 Applicants Must Identify Purposes for Proposed RVC. 2. Consider whether the proposed commitment could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which an RVC that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion, for example, if this type of RVC is necessary to address GAC Consensus Advice. If not duplicative, please explain why you believe the commitment is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed commitment could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any commitments that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed commitment could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any commitments that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed commitment requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN. 6. For further guidance on the aforementioned considerations, please see Section 7.8.3.3 Registry Commitments Evaluation Criteria 7. [If the commitment is being proposed as an Application Change Request]: If the commitment is being proposed in response to an objection, GAC Member Early Warning, GAC Advice, or application comment, please provide a reference to the item to which the commitment responds
The commitments address a structural fact about the applying entity directly, in the contract: the applying entity is a for-profit Delaware corporation and has taken outside investment. The two commitments make the community's position independent of who owns the Registry Operator. Under the governance commitment, who may hold and use .agent names is directed by the Foundation, not by the operator's shareholders, and the obligation is enforceable by ICANN Contractual Compliance, with the PICDRP available to parties claiming harm. The successor-continuity commitment makes the arrangement run with the registry: assignment of the Registry Agreement by the Registry Operator requires the Foundation's prior written approval, and any successor assumes the Community Registration Policies and the governance commitments in full. The commitments bind the applying entity's own future decisions as much as any assignee's, and a change in the ownership of the Registry Operator does not release it from them. No requirement of law, ICANN agreement, or Consensus Policy obliges a registry operator to follow the instructions of an external governance body or to condition assignment on its approval; the Base RA's own assignment rights are supplemented, not duplicated. No objection, GAC advice, or comment prompted these commitments. They are part of the application's design at filing.
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
1. An applying entity may use this response field to submit any additional, optional information or documentation that the applying entity believes enhances understanding of its application or may be of interest to the general public. This could include, but is not limited to, the applying entity’s: a) Individual registry policies; b) Separate agreement with a third-party to fulfill certain commitments; c) Terms of use; d) Additional Community Registration Policies not intended for RA inclusion; e) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD. Notes: 1. This question is optional and for informational purposes only. 2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity. 3. All submissions to this question will be posted for the public to review and comment.
The definition field in Question 132 is limited to 255 characters; the complete community definition appears in Question 133. The two texts state the same community; the shorter is an abridgment to the field limit.
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true