Skip to main content

Stack9 AI Agents

Stack9 AI Agents is a native capability of Stack9 Core for building, configuring and running AI agents that work inside your instance's authenticated workflows. Agents run on Amazon Bedrock AgentCore, read and act on Stack9 data through the Instance MCP server, and are operated over their lifecycle in Stack9 AI Studio.

This page explains the architecture: what an agent is made of, how several agents work together, how answers are grounded, and how an agent is scoped to the person it is helping. How agents are governed and assured is covered in AI governance.

Scope of this page

This is a concept and architecture page. Stack9 AI Agents and Stack9 AI Studio run on Amazon Bedrock AgentCore, outside the Stack9 Core codebase, so this page does not document their configuration schema or console screens. The Stack9 Core side of the integration, the Instance MCP endpoint, is documented in full in MCP Server and the MCP API reference.

What is a Stack9 AI Agent?​

An agent is a versioned artefact. You do not edit a running agent: a change to any element creates a new version snapshot, and versions can be compared side by side. An agent version is defined by:

ElementWhat it sets
System promptThe agent's instructions, persona, tone rules and standard phrases
ToolsThe MCP tools and Connectors the agent may call: its permitted sources
SkillsThe specific tasks the agent may perform, declared explicitly so its scope can be reviewed rather than inferred from a prompt
MemoryWhat context the agent carries within and across sessions
Retrieval scopeWhich indexed content and live sources it may read
GuardrailsProhibited content categories and out-of-scope behaviours, enforced at runtime by AgentCore Guardrails
ModelThe foundation model and version, consumed as a service and pinned

No model is mandated. AgentCore runs a wide range of models behind one consistent API, so the model can be changed or upgraded without redesigning the solution. A new model version is treated as a change and regression-scored before it is adopted (see AI governance).

The diagram below shows the anatomy of an illustrative agent in an insurance claims setting. The agent, its tools and its knowledge are examples, not shipped artefacts.

Separate agents are configured for separate jobs, each with its own prompt, tools, skills and memory, rather than one agent attempting everything.

Why agents are built this way​

Most AI features in digital experience platforms stop at marketing content. Stack9 AI Agents are designed to work across authenticated, enterprise-wide workflows: the same records, workflows and systems of record your back-office users work with. That raises the bar on three things, and each design choice on this page answers one of them:

  • Accuracy. In a regulated domain an incorrect answer is the main risk. Agents answer only from approved sources, show where each claim came from, and decline when they cannot support an answer.
  • Authority. An agent must never reach further than the person it is helping. Agents act under the user's own identity, and every call is authorised by the same permission model as the rest of Stack9.
  • Change control. Agents change over time. Treating each version as an artefact that is evaluated before release makes that change reviewable and reversible.

How it works​

Multi-agent patterns​

Stack9 AI Agents support several complementary patterns. They can be combined in one solution.

PatternHow it works
Orchestrator plus specialistsAn orchestrator interprets the request and delegates to specialist agents. Each specialist reaches data only through named tools, so a step a human specialist performs today (checking a submission against a rule, verifying a document) becomes an individually testable operation.
Intent triageA triage orchestrator classifies what the user is asking (a simple factual question, a guided scenario, or something outside the agent's authority) and dispatches it to the specialist best suited to answer.
Verification agentBefore anything reaches the user, a separate agent checks the assembled answer against what was actually retrieved, confirming every claim traces to a source and the citation matches.
Scheduled jobsAgents triggered on a time or event basis for recurring or batch work.
Agentic orchestrationAgents delegate to one another to complete a multi-step process.

The same orchestrator-plus-specialists architecture can serve a customer-facing enquiry channel and a back-office assessment channel, so both share one design rather than two.

The illustrative scenario below shows orchestration in a claims setting. The agents and tool names are examples of what a solution might configure; they are not shipped with Stack9.

Grounding: accuracy comes from constraint​

Agents answer from the client's approved sources, queried at the time of the question. Three mechanisms work together:

  • Live retrieval through MCP tools. Structured data (records, attributes, statuses) is read live through MCP tools exposed via Amazon Bedrock AgentCore Gateway, each backed by a Stack9 Connector into the relevant system, or through a Stack9 instance's own Instance MCP server. Nothing is copied ahead of the question, so there is no cached copy to go stale.
  • Version-stamped retrieval-augmented generation (RAG). Document content that no API exposes as a query (policies, guidance, rule text) is embedded into a vector index, version-stamped, and re-indexed on a scheduled and event-driven basis. Superseded versions are retained under audit, and every answer carries a link to the source and the version applied.
  • Deterministic calculation. Where an answer depends on arithmetic, agents use a sandboxed code interpreter, so the value is computed and can be shown rather than generated by a language model.

No model is trained or fine-tuned on client content. Grounding on live content keeps answers aligned to the current source and keeps non-public data out of any training path. The reasoning is set out in AI governance.

Indexing and caching are a performance measure, not a default. They are introduced only where a source cannot be queried in real time or where measured latency requires it, and content that is held rather than queried shows its currency to the user.

Refusal and escalation​

Where a question is complex, outside coverage, or not answerable from the approved sources, the agent says so and offers a handover instead of generating an answer. Refusal is designed behaviour, not a failure mode.

  • Escalation is offered on request at any point, and automatically on a refusal.
  • The handover raises a case in the client's contact-centre or case-management system through the client's integration platform, carrying the full transcript and the agent's findings, so the person picking it up has complete context.
  • Triggers, thresholds and wording are configurable, and escalation and refusal rates are reported as service measures.

Three-state findings​

Where an agent reviews a submission against rules, each check returns one of three findings:

FindingMeaning
CompliesThe material satisfies the rule, and the source is cited
Does Not ComplyThe material fails the rule, and the source is cited
Attention RequiredThe material does not let the agent decide either way

Nothing is silently approved. The draft sets out what was checked, the material relied on, and the source behind every finding.

A draft finding is never a decision

Findings are assessment support. Decision authority stays with the client's people and systems of record.

Back-office users see the draft as a structured chain (the rule applied, the data matched against it, the resulting finding) next to the source text, and agree with or override each finding individually. Behind any finding they can open the agent's reasoning: the tool calls it made, the evidence retrieved, and the trace of how it reached its conclusion. They can question the responsible specialist agent directly, then override the finding or ask the agent to work through it again. Every adjustment is versioned with user, timestamp and change history, and any interaction can be flagged for AI Agent configurators to review.

Agents act as the user, not as a service account​

Each agent call into an external system runs under Amazon Bedrock AgentCore Identity, using the credentials and permissions of the back-office user or authenticated customer the agent is assisting, not a shared service account.

  • An agent working for a back-office user is scoped to exactly what that user may see and do. It cannot reach further than the person it supports could reach directly.
  • Every AI-driven action is individually attributable in the audit trail.
  • Anonymous sessions reach only public content.
  • MFA is inherited from the client's identity provider policy.

The Stack9 Core side of this is enforced by the Instance MCP endpoint. Every MCP request must carry an OAuth 2.1 access token that is audience-bound to that one endpoint and carries the identity of the Stack9 user who approved the grant. Each tool is authorised against that user's own app roles before it runs. See MCP Server: Security model.

How agents reach Stack9: the Instance MCP server​

Every Stack9 instance can publish selected query-library queries and webhook automations as MCP tools at /api/mcp/{mcpKey}. This is how an agent reads Stack9 data and triggers Stack9 automations. It is the same governed API surface as the REST API, with an MCP-shaped door onto it: an agent's call is authorised no differently from a human user's.

  • Configure the tools an agent may use in an MCP config. See MCP Server and Exposing MCP tools.
  • Connect an MCP client using the OAuth 2.1 flow. See Connect Claude Code to a Stack9 MCP endpoint, which also covers the confidential-client accommodations used by AgentCore's outbound OAuth provider.
  • Check where you are connected. Every MCP endpoint exposes the built-in stack9_whoami tool, which returns the instance, environment, base URL and acting user. Agents should call it before writing anywhere when the environment is in doubt.

One definition for humans and agents​

Every entity field can carry a description. It renders as hint text on forms generated from that entity, and the same text is carried into the generated input models that query tools advertise to agents over MCP. An agent working with a field therefore draws on the same definition a human sees, instead of forming its own understanding of the term. See Entities.

Conversational and in-form experiences​

Users ask in plain English through a chat interface. Responses stream, so the user sees the answer forming rather than waiting on a blank screen. An assistant can be placed in two ways:

  • As the main stage of an enquiry experience, where the agent asks its own follow-up questions and either answers or raises the escalation itself.
  • As a contextual assistant beside a form, helping the user complete the form in front of them. Each time a step or file is saved, the record's event-driven processing can trigger a background AI job that cross-checks the submission against the applicable rules and feeds the results into the assistant's context. Guidance is advisory; deterministic validation still carries the field.

Replies can render the same brand-approved UI components as the rest of the site: cards, carousels, follow-up question cards and a background-task indicator.

Custom-built UI components

Conversational UI components, history-based personalised guidance, and the placement of the assistant within a client's forms are built once in the client's Web App Template, then reused. They are custom development, not switched on.

Data residency​

AI processing for Stack9 AI Agents runs in the AWS Sydney region (ap-southeast-2): inference, prompts, retrieved content and responses stay inside the same Australian boundary as the rest of the solution. See Hosting and environments.

Limits​

  • Connecting a new data source or tool for the first time needs a developer or power user. After that, business users build and run agents against it independently. Complex, client-specific tool integrations need function-calling development.
  • Evaluation datasets must be authored per client. The tooling is native; the benchmark questions and correct outcomes are written with the client's subject-matter experts.
  • AI answer latency can exceed transactional response-time targets. A complex enquiry involving inference and retrieval is bounded by the model, not by application processing. Responses are streamed, and AI response times are baselined and reported separately from transactional ones.
  • No fine-tuning on client data, by design. This is a deliberate position, explained in AI governance.
  • A draft finding is never a decision. Decision authority remains with the client.
  • Conversational UI components and in-form assistant placement are custom-built, then reusable.
  • AI prompt-to-app is on the roadmap, not shipped. Stack9 Console remains the supported configuration layer.
  • ISO 42001 is a target (Q2 2027), not held.