Model Context Protocol integration
Agents discover tools, schemas, and resources through MCP—stdio for local runtimes, streaming interfaces for remote orchestration—so capabilities stay in sync as the platform evolves.
For AI agents
Agent Integration
ARDA is the AI-native research discovery engine—built from the ground up for AI agents, not retrofitted with an API after the fact. Every tool surface, typed output, session model, and governance policy was designed for programmatic invocation first. This hub orients integration builders before they dive into MCP details, SDK patterns, and REST resources.
Persistent agent sessions
Sessions preserve budgets, hypotheses, and ledger references across steps. Research behaves like a program with state, not a one-shot prompt, which is essential for multi-phase discovery.
Autonomy policies
Policies define how far an agent may progress without human gates: which tools are callable, which promotion tiers are allowed, and how spend maps to campaign priorities.
Well-known discovery
Standard endpoints advertise manifests and integration metadata so new agents attach to the correct tenant, retrieve capability shapes, and avoid brittle hard-coded configuration.
Integration architecture
External agents and services connect to ARDA through a layered architecture designed around the principle that every tool invocation, every data retrieval, and every claim promotion passes through the same governed pipeline regardless of the integration surface used.
At the outermost layer, agents discover ARDA through well-known endpoints that advertise the platform's capability manifest. This manifest describes every available tool, its input and output schemas, and the governance constraints that apply. Agents use this manifest to negotiate which operations they can call rather than hard-coding endpoint paths or parameter shapes.
The next layer manages sessions. Unlike stateless HTTP calls, ARDA sessions carry context across multiple invocations: the hypotheses under investigation, the discovery modes already attempted, the budget remaining, and the current position within the governance tier system. This statefulness means a multi-step research workflow can be expressed as a sequence of tool calls within a single session rather than reconstructed from scratch on every interaction.
Session lifecycle
Agent sessions in ARDA follow a well-defined lifecycle that balances flexibility with governance. Understanding this lifecycle is essential for building integrations that behave predictably across multi-step research workflows.
Initialization
A session begins when an agent authenticates and declares its intent: the project context, the campaign scope, and the autonomy policy it wishes to operate under. The platform validates these parameters against the tenant's configuration and returns a session token that carries the negotiated permissions. If the requested policy exceeds what the tenant allows, initialization fails with an explicit error describing which constraints were violated.
Active research
During the active phase, the agent issues tool calls against the session. Each call is validated against the session's autonomy policy before execution. The session accumulates state: discovery results, intermediate artifacts, ledger entries, and governance events. Agents can query session state to decide next steps—for example, checking whether a previous symbolic pass found enough structure to justify a CDE follow-up, or whether the budget allows another neural discovery run.
Completion and handoff
Sessions end explicitly or through timeout. On completion, the platform finalizes all pending ledger entries, records the terminal session state, and optionally generates a session summary artifact that downstream systems can consume. If claims were promoted during the session, their promotion events are sealed with the session's evidence context. Agents can also suspend sessions for later resumption, preserving state for workflows that span hours or days.
Capability manifests
Every ARDA tenant exposes a capability manifest—a machine-readable document that describes the tools, resources, and governance constraints available to integrating agents. Manifests are versioned and change only through deliberate platform updates, giving integration builders a stable contract to develop against.
A manifest entry for a discovery tool includes its input schema (what parameters it accepts), its output schema (what the result looks like), the governance tier required to invoke it, and any side effects it produces (such as ledger entries or artifact creation). This level of detail means agents can make informed decisions about which tools to call without trial-and-error exploration.
Manifest negotiation happens during session initialization. The agent presents its requested capabilities, the platform intersects that request with the tenant's configuration and the session's autonomy policy, and the session begins with a resolved set of available tools. If the platform adds new tools in a future release, existing sessions are unaffected—only new sessions pick up updated manifests, preventing mid-workflow surprises.
GET /.well-known/arda-manifest
{
"version": "2025-06",
"tools": [
{
"name": "discover.symbolic",
"description": "Run symbolic discovery on a prepared dataset",
"input_schema": { ... },
"output_schema": { ... },
"governance": { "min_tier": "explore" },
"side_effects": ["ledger_entry", "artifact"]
},
...
],
"resources": [ ... ],
"policies": { "max_session_duration": "PT4H" }
}Autonomy policies in depth
Autonomy policies are the mechanism that makes unsupervised agent operation safe. Rather than relying on agents to self-limit, policies define explicit boundaries at the platform level. They are versioned, auditable, and enforced on every tool call.
Tool-level permissions
Each policy specifies which tools the agent may invoke. A conservative policy might allow only read operations—data profiling, artifact retrieval, and ledger queries—while a permissive policy might also allow discovery runs and claim creation. Tool-level permissions prevent agents from performing operations that their deployment context does not warrant.
Promotion ceilings
Policies define the highest governance tier an agent can promote claims to. An automated screening pipeline might be allowed to promote claims to the Validate tier but not to Publish, ensuring that the final step always involves human review. Promotion ceilings create natural handoff points between automated and manual workflows.
Budget and rate constraints
Policies can cap the computational budget a session may consume, expressed in terms that map to the campaign's resource allocation. An agent that exhausts its budget receives an explicit error rather than having its calls silently degraded. Rate constraints prevent bursts that could affect other tenants on shared infrastructure.
Policy versioning
Every policy change is recorded. When a session is audited, the exact policy version it operated under is available in the ledger. This means compliance teams can verify that an agent's behavior was consistent with the permissions that were in effect at the time, even if those permissions have since changed.
Building your first integration
A typical integration follows a sequence: discover the manifest, open a session, issue tool calls, handle results, and close the session. Below is a simplified flow for an agent that runs a symbolic discovery pass and retrieves the resulting claims.
# 1. Discover capabilities
manifest = fetch("/.well-known/arda-manifest")
# 2. Open a session with an autonomy policy
session = arda.sessions.create(
project_id="proj_abc",
campaign_id="camp_xyz",
policy="discovery-only"
)
# 3. Profile the dataset
profile = session.tools.call("data.profile", {
"dataset_id": "ds_001"
})
# 4. Run symbolic discovery
run = session.tools.call("discover.symbolic", {
"dataset_id": "ds_001",
"constraints": profile.suggested_constraints
})
# 5. Retrieve claims from the run
claims = session.tools.call("claims.list", {
"run_id": run.id,
"tier": "explore"
})
# 6. Close the session
session.close()This example uses pseudocode; the actual implementation depends on whether you are connecting through MCP (where tool calls are part of the protocol), the Python SDK (where methods are typed), or the REST API (where each step is an HTTP request). The conceptual flow remains the same across all surfaces.
Next: connect through MCP, mirror critical flows over REST if needed, and align autonomy policies with your risk committee.