From Dashboard to Agent: Turning AI Analytics into Action

Every organisation has a dashboard that someone looks at on Monday and says, "that is odd." Then the meeting moves on. The chart did its job, which was to show something. What happens next, which is deciding who is responsible, working out what a sensible response looks like and building it, is a separate project that starts from scratch and often never starts at all.

This post is about closing that gap. It describes how the Swfte Intelligence Platform is designed to let you analyse and visualise your data, usage, agents and outcomes, and then build agents, workflows and solutions directly from what you see. Much of what follows is design intent, and we say so where it is. We also say what is built today.

Why do dashboards stop at the chart?

A dashboard is a read-only view of a number. It has no idea who owns the number, who is allowed to change what drives it, or what a safe response would be. Those facts live somewhere else: in a directory, in a ticketing system, in a policy document, in somebody's head.

So the person looking at the chart has to leave the chart to answer four questions.

1. Who owns this? The team, the cost centre, the service.
2. Who can approve a change? Not who is senior, but who actually has the authority.
3. What is the response? Is it an alert, a report, a routing change, a cap, an investigation?
4. How would we know it worked? What is the baseline and what is the measure?

Each of those answers takes time to find, and each is easy to get wrong. A reporting line that changed in the spring, a group that was renamed, an approver who left: the facts go stale quietly. The result is that the response is slow, or it is addressed to the wrong person, or it is never built.

What changes when the chart sits on a graph?

The Intelligence Platform is built around a customer-hosted graph of the organisation. Today the appliance reads people, groups, reporting lines and accounts from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace, and resolves accounts into people. It keeps history rather than overwriting it, and every fact carries an evidence status: observed, corroborated, verified, inferred, stale, disputed or unknown. Our post on what the enterprise graph is goes into the detail.

When the chart is drawn over that graph, the four questions have a place to be answered.

• The owner is a relationship in the graph, with an evidence status and an age.
• The approver is found from the manager chain and group membership.
• The response can be drafted from the pattern the chart shows.
• The baseline is the history of the metric, which is already there.

Service and system ownership, which is where most cost and incident questions end up, depends on collectors for cloud, code, Kubernetes and databases. Those are on the roadmap, and until they arrive the graph can say who a person is and who they report to but cannot say which service they run. That limit matters, and we would rather state it than imply otherwise.

What does "turn this chart into an agent" mean in practice?

It is a design, not a button we are telling you to go and press. The intended flow looks like this.

1. Select the finding. You mark the chart, the time range and the records that prompted the question. The selection and the evidence statuses behind it are captured.
2. Resolve the owner and approver. The graph answers who owns this and who can approve a change.
3. Draft the Trust Profile. Identity, owner, risk level, approved models, data classification, permitted systems, allowed and restricted actions, human approval rule, retention, audit and policy set are pre-filled from the finding and left for a person to confirm.
4. Choose a starting level. New agents start at L1 Assist or L2 Approve. They earn autonomy; they do not receive it.
5. Test against history. Replay the agent against the period that produced the finding, as far as as-of reads allow.
6. Run and record. Every run records identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome.

Agents and workflows are built in Studio, Cortex and Nexus. The wiring from the graph into those tools is on the roadmap. We read it as the intended connection, not as a current feature.

For the detail, see building governed agents from your own insights and turning a finding into a governed workflow.

An example: model spend that does not look right

Suppose the usage view shows spend for one team running well above its own usual pattern. We make no claim about how common that is and we quote no figure, because it is only an example.

A person who sees it needs to know who owns the spend and who can approve a cap. From the graph, the owner is a group, its members are known, and the approver is found from the manager chain. The response the person wants is not an automatic cap. It is a proposal, in the right person's inbox, with the evidence attached.

That is a FinOps agent at L1 Assist, then L2 Approve once its proposals have been accepted on the record. In the style we use for every governed 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 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 routing change; any message to a team outside its scope; any change to a budget.
• Records: identity, usage data read, owner it resolved and that fact's evidence status, model used, proposal, approver, action, outcome.

Notice what the evidence status does here. If the graph shows the owner as inferred or stale, the agent is built to say so and to ask a person, and it does not send a confident message to the wrong team. See usage and cost analytics for the longer treatment.

Why governance has to arrive with the agent, not after it

An agent that was built quickly from a chart, with the access of the person who built it, is exactly the thing a security team worries about. The point of building from the platform rather than beside it is that governance applies from the first run.

• Identity: the agent is a known identity, and an AI acting for a person never has more access than that person.
• Permissions: scoped to each tool and data source, so a policy change alters what the agent can actually do.
• Audit: a tamper-evident record, not a log somebody could edit.
• Human approval: consequential actions wait for a named approver, and the agent cannot approve its own work.

Retrieved content is also treated as untrusted. A document that tells an agent to ignore its instructions is data to be read. It cannot override policy. We cover the controls in AI governance and the levels in controlled autonomy.

What is built, and what is not?

We would rather be plain about this.

Built in the appliance: the temporal graph store with insert-only history and as-of reads; directory sync from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace with identity resolution into people and org structure; a local API for graph, people, groups, coverage and audit; the outbound link with signed typed commands and a kill switch; and packaging for a virtual machine, Kubernetes and air-gapped installs. A pre-model sanitisation gateway is in progress.

Designed for, on the roadmap: cloud, code, CI/CD, Kubernetes and database collectors; SaaS, business-system and document sources; a context-package API and MCP server; an action gateway with approvals; the production control plane; marketplace delivery; and the wiring into Cortex, Nexus, Studio and the Nexus harness. The graph explorer, ownership maps, timelines and dashboards are likewise design intent. We give no dates.

How do you know it worked?

Because you started from an insight, you started with a baseline. The same views that showed the problem can show whether it is moving, and the outcome is written back into the graph as evidence. That is the last stage of the loop: connect data, analyse, visualise, decide, build, govern, measure, learn. Our post on the intelligence loop explains why the final step matters most.

Cost belongs in the measure too. An agent that fixes the problem but costs more in model usage than the problem was worth is also a finding.

Where to go next

Start with the Swfte Intelligence Platform overview, then Analyse and Visualise. For the wider category, read Sovereign Intelligence explained. Swfte does not hold SOC 2 or ISO 27001 attestations and does not sign HIPAA business associate agreements today (a SOC 2 Type I audit is in preparation; see the trust page), and the platform is built for compliance-by-design: it provides technical controls, governance mechanisms and evidence, and the exact posture depends on your use case, jurisdiction, deployment and configuration. To talk through your own dashboards, talk to our team.