Platform / Intelligence / Build agents

Build governed agents directly from your own insights

Turn this chart into an agent: the metric, the owner and the permitted systems carry across, and the agent starts under limits.

Most agents begin as a blank page and a guess about what the agent should watch. This page describes the other way round: you start from something you have seen in your own data, usage or outcomes, and the agent is defined from it. It is design intent for the Intelligence Platform, built on the governed-agent model the rest of the platform already uses.

Why start from the insight

An agent that is built without reference to a real finding tends to be built for an imagined problem. It watches the wrong thing, asks for access it does not need, or duplicates work someone already does. An agent built from a finding starts with the answers to the hardest design questions: what is it for, what does it need to read, who is responsible for it and who approves what it proposes.

In the Intelligence Platform those answers are designed to come from the graph and from the view you were looking at. The metric is the thing the agent watches. The owner is the person or group the graph resolved. The systems in scope are the ones the finding touched. The evidence behind the finding goes into the agent’s record, so a reviewer can see why it exists.

This is the first half of building from insight: define the agent from what you saw. The second half is governing it, and that begins at the same moment.

From a chart to an agent, step by step

The intended flow. Agents are built in Studio, Cortex and Nexus. The wiring from the graph into those tools is on the roadmap.

  1. 01

    Select the finding

    Choose the chart, the pattern or the group of records that prompted the question. The selection, its time range and its evidence statuses are captured.

  2. 02

    Resolve the owner and approver

    The graph answers who owns this and who can approve a change. Today it can do this from reporting lines and group membership. Service and system ownership depend on collectors that are on the roadmap.

  3. 03

    Draft the Trust Profile

    Identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed and restricted actions, human approval rule, retention, audit and policy set. Each is pre-filled from the finding and left for a person to confirm.

  4. 04

    Choose the starting level

    L1 Assist or L2 Approve. A new agent has no record, so it earns autonomy rather than receiving it.

  5. 05

    Test against the evidence

    Replay the agent against the history that produced the finding, as-of reads allowing, and check that it would have noticed what you noticed.

  6. 06

    Run, record, review

    Every run records identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome.

Governed from the first run

Governance is runtime, not paperwork. The agent acts as a known identity, and that identity has permissions scoped to each tool and data source. A policy change alters what the agent can actually do, and does not merely change what a document says it should do.

The agent never has more access than the person who built it, and it never has more than its Trust Profile grants. Retrieved content is treated as untrusted, so a document that tells the agent to ignore its rules cannot override policy. Actions reach the outside world only through typed, approved and audited capabilities. The action gateway that carries them out is on the roadmap, and the design principle is that an agent proposes and the gateway decides.

Autonomy rises by level on the record. An agent that has had its recommendations accepted can move from L1 Assist to L2 Approve, then to L3 Supervise, where it acts within limits and is monitored. Many agents should stay at L2 or L3 permanently. An agent cannot raise its own level.

Reviewing an agent that was built from a finding

Review is easier when the agent has a stated reason. A reviewer can ask three plain questions. Does the agent’s scope match what the finding touched? Is each permission in its Trust Profile needed to act on that finding? Is the named owner a person who can be held to account? An agent whose scope is wider than its finding is a design smell, and the review is where it is caught.

The same record supports retirement. When the metric the agent was built to watch has recovered and stayed recovered, the finding that justified the agent no longer holds, and the owner can retire it on the record. Agents that outlive their reason are a large part of how an organisation ends up with an estate it cannot account for.

Kinds of agent you might build from an insight

Examples of the pattern, not a catalogue. The three worked examples below are described in full.

  • A watcher

    Monitors a metric or a pattern that you found and tells the owner when it recurs. Read-only, and a sound first agent.

  • A preparer

    Drafts the response a person would otherwise write: a report, a proposed cap, a routing decision. A person approves before anything happens.

  • A router

    Sends work to the owner the graph resolves, with the evidence attached and the evidence status stated.

  • An investigator

    Gathers the records around a policy decision or an incident and assembles them for a reviewer.

Two agents, built from two insights

Spend anomaly to FinOps agent

You see
Model spend for one team is running well above its own usual pattern.
The graph answers
Who owns this, and who can approve a cap?
It becomes
A FinOps agent that watches usage and cost, and proposes caps to the right person.

AI FinOps Agent

Can
  • Read usage and cost records for the teams it is scoped to
  • Compare spend with the previous period
  • Resolve the owning group and the approver from the graph
  • Draft a spend report and a proposed cap
Cannot
  • Change a budget or a routing rule on its own
  • Approve its own proposal
  • Read unrelated personal data
  • Pause another team’s agents
Requires approval
  • Applying a cap or a routing change
  • Any message to a team outside its scope
  • Any change to a budget
Records
  • Identity
  • Usage data read
  • Owner it resolved, with its evidence status
  • Model used
  • Proposal
  • Approver
  • Action
  • Outcome

Starts at: L1 Assist, then L2 Approve once its proposals have been accepted on the record.

Built today: People, groups and reporting lines, so the approver can be found from the manager chain.

Designed for: Service and cost-centre ownership, which depends on the collectors that are on the roadmap.

Usage and cost analytics

Policy-violation spike to SecOps response

You see
Policy deny decisions on agents are rising in one part of the organisation.
The graph answers
Which agents and owners are involved, who gets told, and who can approve containment?
It becomes
A SecOps response agent that assembles the evidence and brings in the right people.

SecOps Response Agent

Can
  • Group policy decisions by agent, owner and tool
  • Pull each agent’s Trust Profile and recent actions
  • Open an incident with the evidence attached
  • Notify the owner and their manager from the graph
Cannot
  • Disable an agent or revoke a credential on its own
  • Change a policy
  • Read content outside the incident scope
Requires approval
  • Containment: pause, kill switch or credential revocation
  • Any policy change
  • Any external notification
Records
  • Identity
  • Events examined
  • Owners notified
  • Policy applied
  • Decision
  • Approval
  • Action
  • Outcome

Starts at: L1 Assist. SecOps agents are in beta.

Built today: People, reporting lines and the tamper-evident audit record.

Designed for: Agent-to-owner mapping from live systems, and the action gateway that carries out approved containment.

SecOps agents

How building agents connects to the closed loop

Build is the fifth stage and Govern is the sixth. An agent built from an insight is governed from its first run, and what it does is measured and fed back into the graph.

The same eight stages are listed in order below.
  1. 01 · Layer 02Connect dataBring directory data today, and more systems over time, into a graph that lives in your environment.
  2. 02 · Layers 02 and 03AnalyseAsk questions in plain language, explore the graph, and look for trends and anomalies.
  3. 03 · Layers 02 and 03VisualiseSee the organisation, usage, agents and outcomes as maps, timelines, dashboards and evidence views.
  4. 04 · PeopleDecideChoose the response with the owner, the approver and the evidence status in front of you.
  5. 05 · Layers 04 to 06BuildTurn the insight into an agent, a workflow or a packaged solution.(this page)
  6. 06 · Trust FabricGovernIdentity, permissions, policy, audit and human approval apply while the thing runs.(this page)
  7. 07 · Layer 06MeasureTrack the outcome and the cost against the reason you built it.
  8. 08 · Layer 02LearnFeed what happened back into the graph, so the next question starts from more evidence.

Frequently asked questions

Can I really build an agent from a chart?

It is the design. The wiring between the graph and the tools where agents are built, Studio, Cortex and Nexus, is on the roadmap. Agents themselves are built in those tools today, and this page describes how an insight is meant to become their starting point.

What does the agent inherit from me?

The context of the finding, and nothing about your access. It never has more access than you, and its own permissions come from its Trust Profile.

Which level does a new agent start at?

L1 Assist or L2 Approve. Autonomy rises by level as the record shows the agent has earned it, and the accountable owner makes the change.

Who is responsible for the agent?

The owner in its Trust Profile, resolved from the graph where it can be and confirmed by a person. An agent with no named owner is not meant to run.

Can the agent act on its own?

Only within its limits and its level. Consequential actions require a named approver, and the agent cannot approve its own proposals.

How do I know the agent worked?

You measure the outcome against the reason you built it, and the record shows what the agent read, decided and did. The outcome then becomes evidence in the graph.

Take build agents from insight further with Swfte

Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.

Build this in Studio

Describe what you need in plain language. Studio builds the agents and workflows, and you keep every version.