How it fits in your stack

One call gives your agent the context it needs.

Request

Your sources

  • Google Drive
  • GitHub
  • Slack
  • PostgreSQL
  • +

Context Run

Tensor doesn'tCarry out the requestMake decisions for your agentChange your source systems

Your rules

You define what a request requires.

A Context Model says what each kind of request must establish, and the rules for settling it. Tensor checks every run against it.

Example definition
task: assess_change_of_controlrequires:  - executed_agreement  - amendment_chain  - change_of_control_clause_agrees  - disclosure_schedule_current  - outside_counsel_advicerules:  freshness: the schedule is no older than the latest amendment

How it works

  • Define a requestSay what a request requires. Each requirement can be required or optional.
  • Set the rulesDecide how settled it has to be, such as how fresh the evidence must be.
  • Same every runEvery run is checked against it, so the same request gets the same kind of answer.

What it returns

A verdict, the evidence, and what would resolve it.

Before your agent acts, Tensor returns a Context Run, with a Context Manifest inside it: whether the context is enough, what that rests on, and what to do about the rest.

Example Context RunRUN_7D41C2
Outcome
insufficient1 of 5 requirements established · 6 records read
Requirements
  • Executed agreementEstablished
  • Amendment chainNot found
  • Change-of-control clauseContradictory
  • Disclosure scheduleStale
  • Counsel adviceRestricted
To resolve
  1. 1Provide Amendment No. 2 (Data room)
  2. 2Confirm which governs: MSA §14.2 or Disclosure schedule 7.3
  3. 3Counsel advice is privileged — request access or a summary from the matter lead

Context Manifest

The context assembled for this request.

  • Evidence: the information the request depends on, gathered from permitted sources.

  • Context sufficiency: whether the context is enough for the request, and if not, why.

  • Boundaries: what Tensor could and could not access.

  • Trace: what it used, and how it reached the result.

Your agent decides what to do next. Tensor doesn't act for it.

SDK

Add it to your Python code.

Your agent keeps its own model and framework; Tensor handles the context.

python
>>> result = client.context(
      task="assess_change_of_control",
      actor="diligence_agent_prod",
      scope="agreement:MSA-0417",
    )

✓ result.outcome -> insufficient

✓ result.evidence -> 6 records, with provenance

API

Call it from any application.

Send one HTTP request from any stack.

http
POST /v1/context
{
  "task": "assess_change_of_control",
  "actor": "diligence_agent_prod",
  "scope": "agreement:MSA-0417"
}

✓ 200 OK

✓ application/json: a Context Run

MCP

Let your agent use it as a tool.

Your agent calls Tensor like any other tool, inside the framework it already runs in.

agent · mcp
agent › get_context(
          task="assess_change_of_control",
          actor="diligence_agent_prod",
          scope="agreement:MSA-0417"
        )

✓ tool result: a Context Run

✓ the agent reads the outcome before it executes

CLI

Run it on your machine.

Work with Tensor from your own machine.

zsh
$ gammx run --bundle <bundle> \
    --task assess_change_of_control \
    --actor diligence_agent_prod \
    --scope agreement:MSA-0417

✓ Context Run written

✓ outcome: insufficient