LLC formation for AI agents: a real US company, KYC to EIN

Form a real US LLC for an agent's identity. Verified founders go in, a company with an EIN comes out, and the entity becomes what the persona's domains, inboxes, numbers and cards attach to.

Why an agent needs a legal entity

Almost every autonomous business runs into the same wall on day one. The agent can research a niche, write, render, post and reply, but it cannot own anything. A domain registrar wants a registrant. A payments provider wants a business. A vendor wants an EIN on the W-9. The liability of whatever the agent does has to land somewhere, and "a script running on someone's laptop" is not an answer a state, a bank or a counterparty accepts.

Company formation was built for humans: notarized signatures, a physical registered office, a letter from the Secretary of State. An agent cannot sign paper or receive mail at a street address. So the entity ends up being formed by hand, out of band, and the agent inherits it as a pile of PDFs in someone's inbox. Nothing in the runtime knows the company exists.

The LLC primitive closes that gap. It incorporates a real US company for an agent, and it does so inside the identity model, so the entity is a first-class thing the rest of the persona attaches to rather than a document filed away somewhere.

Where formation sits in the identity model

An identity is a named, described persona an agent acts as in the world. It has a name and a description so the model knows who it is being, and it owns concrete endpoints: the domains it sends and receives on, the emails and phones it answers as, the connections it has authorized over OAuth, and a write-only vault for the secrets it uses but never reads.

The relationship between agents and identities is many-to-many. One agent can hold several personas and pick one per session; one persona can be shared by several agents. Agents hold a persona through a grant, not a field on the agent, and the acting persona is named on the run, so choosing one rewrites nothing on the agent and mints no new agent version.

Formation is the layer underneath those endpoints. The order we designed for is:

1. An identity gets created: a persona with a name and a description.
2. The persona gets a legal entity: the LLC formed through this primitive.
3. The entity gets domains, then email on a verified domain, then a phone number with carrier registration.
4. Money attaches last: cards with a hard spend cap the agent cannot raise.

Each of those steps is its own primitive with its own page. The endpoints are gated by the identity's policy; the cards carry a cap the agent cannot raise. The entity is what makes them belong to something real. billing@acme.com is an inbox on a domain that a company owns, not an anonymous mailbox.

The funnel: KYC to EIN

The primitive is one funnel with four gates. Every gate emits an output the next one consumes, and the whole thing runs as an async job you can watch alongside renders and deploys in jobs.

1. Verify the founders

No company can exist until the people behind it are verified. KYC is a hosted identity check for founders, and it is the gate in front of formation, not an optional add-on. The agent kicks off the check; each founder completes it in a hosted flow; the formation cannot be submitted until every member has passed. We wrote about the verification primitive in Introducing KYC.

2. Submit the formation

With founders verified, the agent submits the formation: the company name, the state to file in, and the description of the business. Submission is where money and legal consequence enter, so it is exactly the kind of action the policy layer is for. Every server-executed tool resolves to allow, ask or deny before it runs. With ask, the session pauses, emits a confirmation event and waits at storage cost until someone approves or denies. With deny, the tool is never offered to the model at all. Set the submission to ask, the way you would any other spending action: the agent prepares it, a person confirms it.

3. State filing

The filing goes to the state through the provider behind the primitive. Your agent does not know which one and does not need to. It sees a job moving through statuses, and the entity name it asked for.

4. EIN and documents

When the state approves, the funnel finishes with the EIN application and the formation documents. The output is an entity the runtime knows about: a name, a state, an EIN, and the paperwork, attached to the identity that asked for it.

That is the whole shape. KYC to EIN, one funnel, no human copying values between portals.

White-label by design

We used to publish a post announcing which incorporation partner we had integrated. That post now redirects here, and it is worth saying why we retired it.

Every vendor behind Vetta is white-labeled. The sandbox provider, the model gateway, the payments processor, the email and telephony carriers, the formation provider: none of them appear in the API, the CLI, the SDK, the dashboard, the docs, or an error message. This is a hard rule for us, not a style preference.

For formation specifically it matters in three ways:

• Your surface is stable. If we change the provider behind the primitive, the primitive does not change. Your agent still submits a formation, still polls a job, still receives an EIN.
• Your users see your product. If you build incorporation into your own platform, the person forming the company sees your brand, not a chain of vendors.
• The agent cannot route around it. There is no vendor API key sitting in the agent's context to misuse. The agent calls a primitive; the credentials that make the filing happen are ours, not the agent's.

The trade-off is that we cannot tell you which firm files your paperwork, and we are comfortable with that. What we can tell you is that founders are KYC-verified before anything is submitted, and that the resulting entity is yours.

Build the rest of the persona on the entity

Once the company exists, the identity around it is ordinary identity work, and that part is fully documented. Create the persona, grant it to an agent, and provision its endpoints:

vetta identity create \
  --name "Acme Labs" \
  --description "Operating persona for Acme Labs LLC"
 
vetta identity attach --agent agt_... --identity idn_...
 
vetta identity email provision --identity idn_... --address hello@acme-labs.com --domain dom_...
vetta identity phone provision --identity idn_... --tier standard \
  --legal-name "Acme Labs LLC" --tax-id 88-1234567 --country US --contact-phone +15555550123

The phone line is the first place the entity pays for itself. The standard messaging tier, the one with real throughput, requires a registered business and a tax ID; the sole_prop tier exists for personas that have neither. An LLC with an EIN qualifies for standard on day one.

The same flow from TypeScript:

import { randomUUID } from "node:crypto";
import { createClient } from "@usenaive-sdk/vetta";
 
const vetta = createClient({
  baseUrl: "https://api.vetta.sh",
  apiKey: process.env.VETTA_API_KEY!,
  fetch: globalThis.fetch,
  idempotencyKey: () => randomUUID(),
});
 
const identity = await vetta.identities.create({
  name: "Acme Labs",
  description: "Operating persona for Acme Labs LLC",
});
 
// agent is the result of vetta.agents.create(...)
await vetta.identities.attach(agent.id, identity.id);

attach is idempotent: re-running a provisioning script answers attached: true, created: false rather than failing, so naive up can reconcile identities by name on every run.

When the agent holds more than one persona, the acting one is chosen per session or per deployment, never by rewriting the agent:

vetta session create --agent Concierge --identity acme-labs
vetta deploy create --agent Concierge --identity acme-labs \
  --cron "0 9 * * *" --budget-usd 5 --prompt "Answer anything waiting in the inbox."

Domain purchase and phone provisioning are approval-gated by default, so the first time an agent tries to buy acme-labs.com for its new LLC, a person confirms it. After that, the persona runs unattended. The full domain story is in Introducing domains.

Building an incorporation flow into your own product

Our old guide on building an agentic incorporation platform also redirects here, because the answer got simpler. You do not build the filing pipeline. You build the funnel around ours.

A working shape looks like this:

• One identity per customer entity. The persona is the unit of ownership. Its name and description tell the model who it is acting for; its endpoints are specific addresses and numbers, not booleans.
• KYC as the front door. Send founders through the hosted check before you let them name a company. The primitive enforces this anyway, but surfacing it early saves a failed submission.
• Formation set to ask. Let the agent prepare the submission and let a human approve the spend. The session holds at storage cost while it waits; nothing is billed for idle compute.
• Provision endpoints in order. Domain, then email on the verified domain, then phone. Each is a primitive with its own readiness gates, and a send attempted before a domain finishes verifying comes back retryable rather than failing.
• Read the audit log. Every control-plane action is attributed to a principal and queryable later, so "who approved this formation and when" is a query, not an archaeology project.

None of this requires vendor contracts on your side. The provider relationships, the carrier registrations and the filing credentials are ours; your integration is the primitives.

Get started

• The primitive: /primitives/formation
• The gate in front of it: /primitives/verification
• Identity concepts: vetta.sh/docs/identity/overview and personas
• The API: vetta.sh/docs/api/identities, the SDK: vetta.sh/docs/sdk/identities, the CLI: vetta.sh/docs/cli/identity

Install the CLI with npm i -g @usenaive-sdk/vetta-cli@^0.4.0, create an identity, and give it a company to stand on.