Core Concepts

This page explains the key concepts you need to understand to use Wire effectively.

Containers

A Container is the fundamental unit of Wire. Each container has its own MCP server, content, and access controls. Containers are queryable immediately after creation.

Container Properties

Property	Description
Name	Human-readable name (randomly assigned, can be manually changed)
Description	What the container is useful for (manually set)
Access	private (requires auth) or public (open access)
Paused	When paused, MCP requests are blocked
Sources	Entries from agent tools and file uploads
Tools	5 standard tools: explore, search, navigate, write, delete

Note

Containers are assigned a random placeholder name like “Prancing Zebra” on creation. You can change the name and description anytime in Container Settings.

Container Lifecycle

1. Created - Container is provisioned and immediately ready
2. Ready - Container accepts MCP connections and agent interactions
3. Paused - MCP requests blocked (can be resumed)
4. Trashed - Soft-deleted with a 14-day recovery window
5. Permanently Deleted - Container and contents removed forever

Sources

Sources are the content you add to containers. There are two ways to add content.

Agent Tools

Available on every container from creation. Agents interact with the container directly through MCP tools:

• wire_explore - Browse the container: what shape it has (entities, structured objects, files) and the entries in it, or one entry by id
• wire_search - Fuzzy hybrid retrieval over raw content (file chunks, agent writes)
• wire_navigate - Raw content traversal from a search match: adjacent chunks, full source, related entries
• wire_write - Save an entry (text, structured data, or markdown)
• wire_delete - Remove an entry by ID

Analysis runs continuously in the background on every container, and it is three separate things. Contextual enrichment, which gives a search hit its surrounding context, runs on everything you save and is free. On top of that sit two optional graphs — the provenance graph (how a new entry relates to what was already there) and the entity graph (the people, companies and things your context is about). Each is its own switch on the container’s settings page, each is on by default, and each costs 1 credit per entry written. Agents do not trigger analysis on demand.

Objects

An object is a named group of same-shaped records: expenses, incidents, deploys, Opportunity. It’s how a container knows that fifty entries written over three weeks are fifty rows of one thing rather than fifty unrelated notes.

Any write can name one. Pass object (and, when the content isn’t already JSON, fields) to wire_write:

{
  "content": "Lunch with the Acme team",
  "object": "expenses",
  "fields": { "amount": 42.5, "vendor": "Acme", "date": "2026-07-24" }
}

The values are stored so they can be filtered and aggregated, not just read as prose. Alongside them the container keeps one field profile per object, built from the writes themselves: which keys exist, what types they hold, and how often each one actually appears.

Field	Type	Present
amount	number	12/12
vendor	text	12/12
reimbursable	boolean	4/12

Presence counts matter more than they look: an agent needs to know reimbursable is missing from two thirds of the rows before it filters on it.

There’s no setup step and no schema to declare. The first write creates the object; later writes widen it. A key that shows up with a new type widens the profile rather than failing the write. Wire records what it was given.

A few rules worth knowing:

• Reuse the name. Same object name for every record of a kind. A fresh name per write turns the profile into noise, and containers cap how many objects they’ll track.
• Case doesn’t fork. Expenses after expenses folds into the same object.
• Names are identifier-shaped. A letter, then letters, digits, or underscores. entries, relationships, and fields are reserved.
• Objects don’t cross sources. Two integrations both writing notes keep separate profiles, so their shapes never smear together.

Connectors and uploaded tabular files produce objects too: a synced Salesforce source contributes its sObjects, and a CSV contributes one object per file.

Objects are also what wire_query reads. That tool is off by default and has to be switched on per container, so most containers answer questions about objects through wire_explore instead. See wire_query.

File Uploads

Upload files through the Wire dashboard. Wire processes them into entries automatically:

• Structured files (CSV, JSON) are parsed into individual entries, one per record.
• Unstructured files (PDF, Word, text, markdown) are chunked into text entries.

After analysis, structured records are available through wire_explore and unstructured chunks are searchable through wire_search.

Supported File Formats

• Documents: PDF, Word (.docx), Text, Markdown
• Data: JSON, CSV
• And more

See Supported File Types for the complete list.

Examples

Container	Content	Result
Wire Docs	Markdown docs, CSVs, JSON	Entity types like features, use cases, and organizations discovered with structured and semantic search
Lenny’s Podcast	RSS feed + transcripts	Companies and people extracted as entity types, 286 episodes searchable by topic

Processing Pipeline

When you upload a file, Wire:

1. Validates - Checks format and size limits
2. Stores - Saves the file securely
3. Parses/Chunks - Structured files are parsed into entries. Unstructured files are chunked into text entries.

Analysis runs separately. Each pass examines a portion of entries, discovering entity types and relationships. Over time, repeated passes build a complete schema available through wire_explore and wire_search.

MCP Tools

Every container ships with 5 tools. No analysis required to start using them.

Tool	Description
wire_explore	See what the container holds, and browse its entries
wire_search	Fuzzy hybrid retrieval over raw content
wire_navigate	Traverse from a search match: adjacent chunks, source, related entries
wire_write	Save an entry to the container
wire_delete	Remove an entry by ID

There is one additional tool beyond the standard five. wire_query runs read-only SQL over a container’s objects for sums, counts, and grouped totals. It is opt-in: every container ships with it turned off on both MCP and REST, and an organization owner or admin has to switch it on from the container’s Tools page before an agent can see it.

See Tools Reference for full details and parameters.

Tool Costs

Wire uses a credit system for tool calls. See the pricing page for current rates.

Organizations

Organizations contain users, containers, and billing information.

Roles

Role	Capabilities
Owner	Full control, billing, delete org
Admin	Manage members, containers, and billing
Member	Create containers, manage the ones they created or were shared with, read-only org settings

An organization role decides what you can do across the organization. Access to any single container is a separate layer: you get it by creating the container or by being shared on it. Owners and admins can see every container in the organization from the Container Management page, but still need to be shared on one to edit it.

One kind of container does not follow that rule. A container created by one of your own agents holding an organization API key (provision mode) has no individual creator, so it is readable by every member of the organization without anyone sharing it. Owners and admins manage it; members get read access. Containers a person creates stay private to that person until they share them.

See Roles & Permissions for details.

Agents

An Agent is a registered third-party integration that authenticates and operates on containers. Agents are how the SDK speaks to Wire on behalf of your users.

Every action an agent takes is attributed in the container’s audit log under the agent’s stable identity, separate from any user underneath. Tool access is scoped per credential, so the same agent can have a full-access credential for one deployment and a wire_search-only credential for another.

See Agents for the full definition.

Authentication

Containers can be public or private (default).

• Public containers are readable by any signed-in Wire user. Connecting takes a sign-in, and read-only access follows automatically.
• Private containers are reachable only by the creator, people holding a grant, and authorized agents.

Either way, a connection is authenticated. Wire uses OAuth 2.1:

1. AI tool initiates OAuth flow
2. User authorizes in browser
3. Token issued with container scopes
4. AI tool makes authenticated requests

See Authentication for details.