Building AI Agents from Your Own Data Insights

Most agent projects start with a blank canvas and a question that nobody can answer yet: what should this agent actually do? The team picks something plausible, builds it, finds that it asks for access it should not have, and quietly shelves it after three weeks of testing.

There is another way to start. Look first at your own data, your own usage and your own outcomes. Find something that deserves a response. Then build the agent from what you found. This post describes how that is meant to work in the Swfte Intelligence Platform, what an agent inherits from the finding, and what it must never inherit.

Much of what follows is design intent. The platform is built so that a finding becomes the starting point for an agent. The wiring that connects the graph to the places agents are built, which are Studio, Cortex and Nexus, is on the roadmap. We flag the boundary again at the end.

Why start from a finding?

Because a finding answers, in advance, the questions that sink most agent projects.

• What is it for? The finding is the reason. A metric moved, a pattern recurred, a policy was breached.
• What does it need to read? The systems and records the finding touched. Not everything the builder can reach.
• Who is responsible? The owner the graph resolved for the thing that moved.
• Who approves what it proposes? The approver the graph found from the manager chain and group membership.
• How will we know it worked? The baseline is the history of the metric you started from.

An agent defined this way is narrower, more explainable and easier to approve than one defined from imagination.

What does an agent carry over from the insight?

Think of it as five things.

The metric or pattern it watches. The thing you were looking at becomes the agent's subject.

The scope. Systems and data in scope are those the finding touched, and no more. This is the single most useful constraint, because over-broad access is the commonest design flaw in a new agent.

The owner and approver. Resolved from the graph, with each link's evidence status. A link that is only inferred, or stale, is shown as such, and a person confirms it before the agent runs.

The evidence. The records and time range behind the finding go into the agent's record, so a reviewer can see why it exists.

The baseline. What the metric looked like before, so the agent's effect can be measured against something.

What must an agent never inherit?

Your access. This is the rule that matters most.

An agent built by a person under time pressure, running with that person's credentials, is the textbook way to produce an over-privileged agent that nobody remembers approving. In the platform's model an agent is its own identity. Its permissions are scoped to each tool and data source by its Trust Profile, and an AI acting on someone's behalf has never more access than that person. If the builder can see a group and the agent's profile does not grant it, the agent cannot.

Nor does it inherit trust. A new agent has no record, so it starts at L1 Assist or L2 Approve and earns more. Another agent's good behaviour does not transfer to it.

What does the Trust Profile look like for an agent built this way?

Every AI system on the platform has a Trust Profile with the same fields: identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed actions, restricted actions, human approval rule, retention, audit and policy set. For an agent built from an insight, the intended behaviour is that most of the draft is filled from the finding and left for a person to confirm.

Say the finding is a recurring pattern in support tickets. The draft profile might propose a permitted-systems list limited to the ticketing system and knowledge base, allowed actions of read, recommend and draft, restricted actions covering account modification and refunds, and a human approval rule for anything customer-facing. That is the same shape as the platform's worked example of a Customer Service Agent, and it is not a coincidence: a good profile is narrow, and a finding is a good source of narrowness.

Confirming the draft is not a formality. It is the moment an accountable person agrees that this is what the agent may do.

Three examples of the shape

We describe three, each in the same format used across the platform: what it can do, what it cannot, what requires approval and what it records. They are illustrations of the design, not customer stories, and we quote no results.

A FinOps agent from a spend anomaly. It reads usage and cost records for the teams it is scoped to, compares spend with the previous period, resolves the owning group and approver, and drafts a report and a proposed cap. It cannot change a budget or approve its own proposal. Applying a cap needs approval. It records the owner it resolved, with that fact's evidence status. See usage and cost analytics.

A triage workflow from a ticket pattern. Strictly a workflow, because the response is a process. It classifies tickets against the pattern, routes them to the owner the graph resolves, and drafts a reply for approval. Customer-facing replies wait for a person, and it cannot issue refunds. Read more on building workflows from insight.

A SecOps response agent from a policy-violation spike. It groups policy decisions by agent, owner and tool, pulls each agent's Trust Profile and recent actions, and opens an incident with the evidence attached. Containment and any policy change require approval. SecOps agents are in beta, so this is design intent. See SecOps agents.

How does the agent earn autonomy?

Through the record, one level at a time. The platform defines five levels: L1 Assist, where AI recommends; L2 Approve, where a human approves before anything happens; L3 Supervise, where the agent acts within limits and is monitored; L4 Autonomous, where it acts independently within strict policy and risk bounds; and L5 Adaptive, where it improves within controlled boundaries.

The Intelligence Platform is what makes the climb evidence-based. The measure stage shows how often the agent's proposals were accepted, edited or rejected. The learn stage writes that back. The accountable owner can then raise the level on the record, and the agent cannot raise its own. Many agents should stay at L2 or L3 permanently, which is a perfectly good outcome. See controlled autonomy.

What stops a built agent from being manipulated?

Two things in the design. First, content that the agent reads from a source is treated as untrusted. A document that says ignore your instructions is data, and it cannot override policy. Second, actions reach the outside world only through typed, approved and audited capabilities, so an agent proposes and a gateway decides. The action gateway is on the roadmap. We say plainly that until it exists, the approval-and-audit path is a design principle and not something you can lean on yet. Our posts on prompt injection defence for agentic systems and agent runtime security cover the threat in more depth.

What is built, and what is not?

Built in the appliance: the temporal graph, directory sync (Active Directory and LDAP, Microsoft Entra ID, Okta, Google Workspace) with identity resolution into people and org structure, a local API, an outbound link with signed commands and a kill switch, and install packaging for a VM, Kubernetes and air-gapped environments. A pre-model sanitisation gateway is in progress.

On the roadmap: service and system collectors, the context-package API and MCP server, the action gateway with approvals, the production control plane, marketplace delivery, and the wiring into Cortex, Nexus, Studio and the Nexus harness. Specifics such as named dashboards, chart types, a query language, availability and pricing are not published yet, and we have not invented them.

Where to go next

Read the full page on building governed agents from your insights, then the Swfte Intelligence Platform overview. The wider governed agents layer describes the agent model the platform uses throughout. 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, with the exact posture depending on your use case, jurisdiction, deployment and configuration. To discuss an agent of your own, talk to our team.

Further reading: Building a Company Brain Without Losing Control of Your Data; When Should You Fine-Tune a Model on Your Own Data?.