Skip to main content

Overview

The Settings page gives you fine-grained control over how the Ops Agent thinks and what it can connect to. Two sections matter most:
  • Ops Agent LLM Controls — persona, model selection, sampling hyper-parameters, and cognitive governance toggles.
  • Integrations & MCP — built-in OS integrations, custom webhooks, and Model Context Protocol (MCP) servers, each with a live connection test.
Use this page when you need to:
  • Make the Ops Agent more deterministic or more creative for a given workload.
  • Set a fallback model so runs survive a primary model outage.
  • Register an external webhook or mount an MCP server as an agent tool source.
  • Verify that an integration handshake works before relying on it in a workflow.

Ops Agent LLM controls

Identity and tone

Define who the agent is and how it communicates:

Model and sampling

Control which model runs and how it generates output:

Cognitive governance

Three toggles gate how the agent reasons. All three are on by default:
  • Anti-Passivity Mandate (Zero Refusal Gate) — the agent must attempt the task rather than deflect or defer.
  • Multi-Step Chain-of-Thought DAG Planning — the agent decomposes work into a multi-step plan before executing.
  • Quality Flywheel Auto-Evaluation & Scoring — the agent scores its own output and feeds the score back into future runs.
Click Save to persist the configuration. Saving updates the orchestrator name, default model, and system prompt on the server.

Secrets vault

The Secrets Vault (API Keys) tab stores provider credentials and bridges them to the live environment. When you save a secret, the platform applies it to the running process immediately. No restart is required, and a connection test run right after saving uses the new credential. To add a secret, enter a provider name and the secret value, then click Save. The vault:
  • Normalizes the provider name to its canonical environment key. For example, hubspot, hubspot_pat, and hubspot_access_token all map to HUBSPOT_PAT; unrecognized providers map to the uppercased provider name.
  • Stores only a masked preview of the value, in the form sk_1••••••••e0a1. Values of 8 characters or fewer show as a fully masked placeholder.
  • Increments the secret’s version each time you update an existing provider.
Recognized provider mappings:

Automatic provider sync

The vault also syncs in the other direction. Whenever you open the secrets or integrations list, the platform scans the environment for five core provider keys and registers any it finds as vault entries and integrations: Instantly (INSTANTLY_API_KEY), HubSpot (HUBSPOT_PAT), ElevenLabs (ELEVENLABS_API_KEY), AgentMail (AGENTMAIL_API_KEY), and Google Gemini (GOOGLE_GENERATIVE_AI_API_KEY). Credentials configured outside the app show up in the vault with a masked preview and a connected status without any manual registration.

Integrations & MCP hub

The Integrations & MCP tab manages three kinds of connections: built-in OS integrations, custom webhooks, and MCP servers.

Built-in OS integrations

Eight integrations ship pre-configured:

Add a custom webhook

Click Add Webhook and provide a name, an endpoint URL, and an optional API key. The integration is stored with type webhook:

Mount an MCP server

Click Add MCP Server to mount a standard-protocol tool source such as PostgreSQL MCP, BigQuery MCP, or Filesystem MCP. Configure:
  • Server Identifier Name — a label like Postgres-MCP.
  • Transport Protocolsse (Server-Sent Events URL) or stdio (local command).
  • Endpoint or command — an SSE URL such as https://mcp.agent-lab.tech/sse, or a CLI command such as npx -y @modelcontextprotocol/server-postgres for stdio.
  • Capabilities — comma-separated list, for example tools,resources.
  • Authorization Token / API Key — optional.
The integration is stored with type mcp:

Integration status

Every integration carries a status field. New integrations default to active unless you supply a different status when creating or updating them.

Test a connection

Each registered webhook and MCP server has a Test action that runs a live handshake through the settings.testIntegration mutation. The test picks the deepest check available for the integration:
  1. Provider-verified checks. Integrations whose name matches a known provider are validated against that provider’s live API using the credentials configured in the environment or secrets vault:
    • Instantly verifies the outbound connection over REST API v2 (Instantly Outbound) using INSTANTLY_API_KEY.
    • ElevenLabs (names containing elevenlabs or pamela) calls the ElevenLabs user endpoint with ELEVENLABS_API_KEY.
    • HubSpot queries the CRM contacts endpoint with HUBSPOT_PAT (also accepting HUBSPOT_ACCESS_TOKEN, HUBSPOT_DEVELOPER_API_KEY, or HUBSPOT_API_KEY).
    If the required key is missing, the test fails with a message naming the key, for example ELEVENLABS_API_KEY is not configured in environment or vault.
  2. Live HTTP ping. If the integration config includes an http:// or https:// endpoint URL, the test sends a HEAD request with a 5-second timeout and reports the actual HTTP status and measured roundtrip latency.
  3. Local fallback. Integrations with no reachable URL are verified as a local profile and report Local Plugin / Runtime Hook (or Model Context Protocol v1.0 (stdio) for MCP).
A successful live ping returns the protocol negotiated, the HTTP status, and the roundtrip latency:
A failed handshake returns success: false with the underlying error, for example an HTTP error code or a timeout message, so you can tell a bad credential apart from an unreachable endpoint. Run a test after adding an integration, and again whenever a workflow that depends on it starts failing, to confirm the endpoint still responds.