When a connected system changes

What this is

Your agents depend on systems you don't control. The finance system behind the invoice exceptions agent can be taken down for maintenance, retired, or upgraded so that an invoice comes back without a field it used to have. Mindset watches for each of these and tells you what they break before an agent runs into them.

This page is for org admins. Each action here is on the connection's page under Connections.

Stop a connection for now

Disable, on the connection's Overview, stops every call through the connection. It's reversible and takes no confirmation. The connection shows a Disabled badge.

Nothing about the connection or what uses it is changed or deleted. While it's disabled:

• Every call through it is refused.
• Every script and function whose live version calls one of its operations is unusable, and so is every agent running such a script, and every agent whose active version gives its model the connection or one of its operations. They show as unusable whether or not they have run since.

Press Enable to turn it back on. Everything it broke clears as soon as it's enabled, with nothing else to change.

Disable the finance system connection while the finance team migrates it, and enable it again afterwards.

Delete a connection

Archive, on the connection's Overview, deletes the connection. The Archive this connection? dialog says it plainly: a deleted connection can't be brought back, anything still using it shows as broken, and its calls through the connection fail. To stop it for now instead, use Disable.

When something live depends on the connection, the first Archive deletes nothing. The dialog shows "N depend on this connection" and names each dependent: every agent, script and function that uses it, and for an agent, the script it goes through. Press Archive anyway to delete. If the list changes before you press it, the dialog shows the new list instead, so what you confirm is exactly what was there.

After the delete, each dependent shows as broken until nothing live of it uses the connection. A deleted connection can't come back, so the repair is to change the dependent: save a new version of the script or function that calls another connection's operation, or remove the connection from the agent's resources and activate that version.

A field the system stops returning

Mindset records the shape of what each operation returns: which fields come back, and their types. A field is established when the connection declares it as required, or when it came back on every one of at least 20 successful calls.

When a successful call returns without an established field, or with that field as a different type, that's a contract break. New fields are never a break, and neither is an empty list.

A break matters only where something live reads that field. Suppose the finance system stops returning due_date from get_invoice:

• The invoice comparison function reads due_date, so its live version is unusable.
• A script that reads that function's output built from due_date is unusable too, and so is the invoice exceptions agent running it. Each verdict names every link in the chain.
• A script or function that doesn't read due_date is untouched.

They turn unusable without having to run. Monitor → Resources lists them under "Broken by a change to something they depend on", with the reason and the repair. An agent's Resources tab also flags an unusable resource it uses.

To repair it, read what the operation returns now, then either change the script or function to read a field it does return and save a new version, or restore the field on the system's side. The alarm clears by itself once a successful response carries the field with its usual type again.

A break does two more things:

• It lapses the operation's tested status, so the next version that calls it meets the go-live gate.
• It re-runs the stored test parameters of every script and function that calls the operation.

Both are explained in Test before it goes live.

Caught when you save

The same record checks a script or function when you save it. A field the operation is known not to return is refused at save, naming what it does return, once the shape is declared or established. While the record is still thin, the save goes through with a warning that says how many calls it rests on. An operation with no successful call at all saves with an "untested" warning.

See what an operation returns

On the connection's Operations tab, each operation has Show recent responses. It shows a summary of the recorded shape and a few recent real responses per outcome (Succeeded, Returned nothing, or Failed), each with when it was captured.

Responses are kept by default, with emails, phone numbers, and card and account numbers removed. The panel says how many days they're kept. When your org keeps none, the panel says so, and that shapes are still recorded.

There's no console control for this. An org admin turns it off or on through the admin MCP (org_admin, verbs get_response_samples and set_response_samples). Off stops new responses being kept, keeps recording shapes, and leaves what's already kept to age out. To erase one operation's kept responses now, use govern_tool with eraseOutputSamples.

Changes that make an operation untested

Some changes you make yourself lapse tested status on the connection's operations:

• Registering an operation again with a different method, path or parameters.
• Pointing the connection at a different base URL.
• Binding a different credential, such as rotating the API key. A routine automatic token refresh doesn't count.

A lapse stops nothing that's already running. It matters the next time a version that calls the operation goes live. See Test before it goes live for the full list and what to do.

What can go wrong

• An agent stopped working and nothing changed in Mindset. Check Monitor → Resources for "Broken by a change to something they depend on". The system you connect to may have changed what it returns.
• You deleted a connection and need it back. You can't. Connect the system again and point the dependents at the new connection's operations.
• Archive keeps showing a list instead of deleting. Something live depends on the connection. Read the list, then press Archive anyway, or Disable instead.
• Activation is refused after you rotated a key. The new credential lapsed tested status. Run the test parameters, then activate.

You're done when

• You disabled and enabled a connection, and saw what it marked unusable in between.
• You know where to look when a connected system changes what it returns.
• You read an operation's recent responses before writing a script that reads its fields.