API Reference

Complete technical reference for the Ejentum harness API. If you have not read the Quickstart, start there. This page is the full specification for builders integrating into production.

Base URL

https://api.ejentum.com

There is one REST endpoint, POST /harness/. The hosted MCP server lives at /mcp; see the MCP Server Guide.

Authentication

All requests require an API key passed as a Bearer token:

Authorization: Bearer YOUR_API_KEY

Generate a key from your dashboard. The free trial issues a key with no card required.

Endpoint

POST /harness/

Match a natural language task against the chosen harness and return the best-fit cognitive operation as a ready-to-inject string. Include the trailing slash.

Request

Request Body

{
  "query": "Evaluate whether a database migration plan that adds a NOT NULL column to a 50M-row table is safe under concurrent writes, given that the backfill uses a trigger-based default.",
  "mode": "reasoning"
}

Modes

Four harnesses, each in two variants. Pass the bare name for dynamic; prefix adaptive- for adaptive.

679 cognitive abilities across the four harnesses. Every harness and both variants are reachable from any paid tier; the free trial runs the four dynamic modes.

Dynamic vs adaptive

Dynamic retrieves the best-fit operation for your task and returns it as-is. The same operation generalizes across many tasks of the same kind. This is the right default for routine work.

Adaptive retrieves the same operation, then rewrites the procedure and the reasoning topology to name the specific variables, files, or framing in your task. The safety locks stay frozen: the failure guard, the suppression list, and the verification checkpoint are identical to the dynamic version. Adaptive costs more compute per call and draws from a separate, smaller monthly pool.

Response: 200 OK

The response is a JSON array with a single object. The object's key matches the mode you sent, so adaptive-reasoning returns an adaptive-reasoning key. The value is a single pre-rendered injection string, ready to drop into your model's context. No field assembly required.

[
  {
    "reasoning": "[PROCEDURE]\nStep 1: Extract every duration estimate and identify its basis: historical data, expert judgment, or optimistic assumption. Step 2: Compare each estimate against historical base rates or p90 benchmarks for similar tasks. Step 3: Flag estimates below the historical median as likely optimistic. Step 4: Never accept best-case estimates as planning targets. Do not anchor to initial optimistic numbers. Step 5: If an estimate lacks historical basis, simulate impact with a 1.5x-2.0x buffer. If data exists, compute the variance-adjusted range. Verify the final timeline accounts for cascading delay propagation across dependent tasks.\n\n[REASONING TOPOLOGY]\nS1:extract_duration_estimates -> N{accept_best_case_estimates_planning_targets} -> S2:identify_basis(historical|expert|assumption) -> FIXED_POINT[historical_base_rates] -> S3:compare(estimate_vs_p90_benchmark) -> G1{below_median?} --yes-> FLAG:likely_optimistic -> S4:apply_buffer(1.5x_to_2x) -> S3[LOOP] --no-> G2{lacks_historical_basis?} --yes-> S4b:simulate_with_buffer -> S3 --no-> C{adjusted_range = base_rate_estimate +/- sqrt(variance) * z} -> S5:apply_adjusted_range -> S6:verify_cascade_delay -> OUT:realistic_timeline\n\n[COGNITIVE PAYLOAD]\nAmplify: hofstadter buffer application; p90 baseline comparison; variance multiplier scaling\nSuppress: best case anchoring; optimism bias\nCognitive Style: realistic duration estimation\nElasticity: coherence=risk adjusted timeline, expansion=conservative\n\n[FALSIFICATION TEST]\nIf time estimates reflect only the best-case scenario without verifying applying any buffer multiplier, duration calibration has defaulted to optimism.\n\n[NEGATIVE GATE]\nThe database migration will take two weeks: that's our best-case estimate and the team is experienced, so there's no reason to add buffer. We'll hit the deadline if everything goes according to plan.\n\n[TARGET PATTERN]\nChallenge the two-week estimate: what do similar migrations actually take? If past projects averaged four weeks at p90, the best-case anchor is dangerously optimistic. Apply a variance multiplier for schema complexity, data volume, and rollback testing: build buffer from the full distribution, not the happy path."
  }
]

This is verbatim production output for the request body shown above. Newlines arrive as \n; the string is meant to be injected exactly as returned.

Response sections

The injection string is divided into labelled sections. The label set differs per harness, but the structure is consistent: a procedure to follow, a reasoning topology (a DAG of steps, decision gates, and meta-cognitive exits), a cognitive payload of signals to amplify and suppress, a verification check, and a named failure pattern to avoid.

Every operation has the same six slots in the same order. Each harness uses its own label for a given slot:

The [COGNITIVE PAYLOAD] block (slot 3) holds the Amplify, Suppress, Cognitive Style, and Elasticity lines.

When you call an adaptive mode, only slots 1 and 2 (procedure and topology) are rewritten to name the specifics of your task. Slots 3 through 6 (the cognitive payload, the verification check, the failure pattern, and the correct-shape example) are returned verbatim, identical to the dynamic version. That is the design guarantee: adaptation changes how the model approaches the task, never which failure modes it is required to block.

Dimensional Routing

Within a harness, the query is matched against every ability and the highest-scoring one is returned. The reasoning harness spans six cognitive dimensions:

Writing Better Queries

Query quality drives retrieval precision. The search engine matches your query both semantically and lexically, so the agent's real task description routes better than a meta-description of what you want.

Key rule: send the agent's actual task, not a description of the intent. The router scores semantic content.

Error Responses

Error Body

{
  "error": "string. description of the error"
}

Adaptive pool fallback

When your monthly adaptive pool is exhausted but your dynamic pool still has calls, requests in an adaptive mode do not fail. They silently fall back to the dynamic equivalent and a response header flags that the fallback occurred, so your agent keeps working. When both pools are exhausted, the API returns 429.

Rate Limits and Quotas

One harness call counts as one call against the matching pool, regardless of mode. Pools reset on a 30-day rolling cycle from the start of your subscription. See Pricing for plan details, or email info@ejentum.com for higher volume.

Platform

The API runs on a global edge network with API key validation, per-key rate limiting, tier enforcement, DDoS protection, and request logging. No internal infrastructure is directly reachable. The only public surfaces are POST /harness/ and the MCP server at /mcp.

Stability

The response schema is stable. Changes are additive only: new sections may appear inside the injection string, but existing keys and the array-with-one-object envelope will not change without advance notice. If the API is unreachable, your agent continues on native model reasoning; the harness is an enhancement layer, not a hard dependency in your execution chain.