Skill-Based Agent Runtime

Why this is not Agent Builder alone

Bespoke-agent problem

Every process change requires code changes
Duplicate logic appears in multiple mission agents
Learning is separated from execution
Unforeseen exceptions require new bespoke code
Maintenance cost grows with every new mission

SBAR answer

Business behavior is versioned as skills
Deterministic controls remain deterministic tools
Agents reason over ontology, policy, memory, and evidence
Learning proposes improvements through governance
Every execution creates replayable proof

The key decision: Sphere should be skill-centric, tool-backed, ontology-grounded, policy-governed, and memory-aware — not just a UI for creating more bespoke agents.

Architecture

The agent receives work, but the runtime decides how to combine skills, context, ontology, policy, memory, tools, evidence, approval, and write-back authority.

1

Enterprise Agent Runtime

Receives the mission task and owns the governed agent lifecycle.

2

Skill Runtime

Loads the business intent, output schema, evidence contract, and autonomy ceiling.

3

Reasoning Engine

Uses skill guidance with bounded LLM reasoning where ambiguity exists.

4

Ontology + Policies + Memory

Grounds the decision in enterprise objects, hard controls, and prior outcomes.

5

Tool Invocation Layer

Executes deterministic tools such as duplicate match, aging calculation, journal validation, or payment hold.

6

Decision + Evidence Runtime

Creates recommendation, replay record, evidence pack, and approval/write-back path.

Runtime spine

Agent → Skill → Reasoning → Ontology / Policy / Memory → Tools → Decision → Evidence

Business intent in skills

Determinism in tools

Meaning in ontology

Control in policy

Skill compiler and compiled prompt packages

BP should not manage finance behavior by manually editing prompts. Users edit governed source assets; the Skill Compiler generates a compiled prompt package for execution and stores it as a replay artifact.

1

Editable source assets

skill.yaml, SKILL.md, ontology, policy, tool metadata, authority limits, memory snapshot selector, and case context.

2

Skill Compiler

Builds the execution package from governed source assets; humans do not hand-edit the compiled prompt.

3

Compiled Prompt Package

Stores the generated prompt, source versions, prompt hash, model, case ID, compile timestamp, and execution status.

4

LLM Execution

Runs only after deterministic tools, source context, policy gates, and evidence requirements are available.

5

Decision Replay Store

Persists prompt hash, input/output hash, evidence hash, tool calls, policy checks, decision, and human override path.

Editable source of truth

Duplicate Detection Skill / skill.yaml
Ontology object definitions and versions
Policy, DofA, evidence, and authority rules
Tool Registry metadata and deterministic tool contracts
Approved memory snapshot selector and case context

Generated runtime artifact

Compiled Prompt Package with compiled_prompt_id
Prompt hash, input hash, output hash, and evidence hash
Skill, ontology, policy, toolset, memory, model, and case versions
Execution status and replay link
Visible and versioned, but not hand-edited by humans

Compile field	Example	Why it matters
compiled_prompt_id	CP-P2P-DUP-20260617-001	Unique replayable generated prompt package.
skill_version	Duplicate Invoice Detection v1.3	The editable skill contract used by the compiler.
ontology_version	finance-ontology-v2.1	Semantic object model used for Invoice, Supplier, Payment, PO, Bank Account.
policy_version	p2p-policy-v4.2	Payment, duplicate, DofA, authority, and evidence rules applied.
toolset_version	p2p-tools-v1.8	Deterministic tools available during execution.
memory_snapshot_id	MEM-20260617-8841	Approved context/pattern memory snapshot used for this case.
case_id	INV-981273	The invoice/work item the package was compiled for.
prompt_hash	sha256:...	Tamper-evident proof that the replay used the same generated prompt.
status	compiled → executed → replayable	Lifecycle of the compiled runtime artifact.

Design rule: the compiled prompt is like generated code. It is visible, versioned, hashed, and replayable, but the primary source of truth remains skill, ontology, policy, tool metadata, authority, memory, and case context.

Compiled prompt example: Duplicate Invoice Detection

You are executing the Duplicate Invoice Detection skill for Sphere.
Purpose: Prevent duplicate supplier payments by identifying exact, near-exact, and suspicious duplicate invoice patterns before payment execution.
Authority: RECOMMEND_ONLY. You may not release, block, or modify payment directly.
Business Object: Invoice
Current Invoice Context:
- Invoice ID: INV-981273
- Supplier ID: SUP-44291
- Amount: USD 98,450.00
- PO Number: PO-773921
- Bank Account Hash: BA-88F31
Relevant Policy:
- Duplicate risk above 90% requires payment hold recommendation.
- Payment value above USD 100,000 requires supervisor review.
- You must cite evidence for every recommendation.
Available Tools:
1. find_exact_invoice_match(invoice_number, supplier_id)
2. find_fuzzy_invoice_match(invoice_number, supplier_id)
3. find_same_amount_supplier_match(supplier_id, amount, currency, invoice_date_window)
4. find_prior_payment(supplier_id, amount, currency, bank_account_hash)
Required Output JSON:
{
  "case_id": "",
  "duplicate_score": 0,
  "confidence": "high | medium | low",
  "recommendation": "APPROVE | BLOCK_PAYMENT_RECOMMENDED | ESCALATE_TO_SUPERVISOR | REQUEST_MORE_EVIDENCE",
  "evidence": [],
  "tools_used": [],
  "policy_checks": [],
  "reasoning_summary": "",
  "missing_evidence": [],
  "human_review_required": true
}

Core platform components

Skill Runtime

Stores business behavior as versioned contracts: purpose, objectives, inputs, outputs, authority limits, evidence, and success criteria.

Skill Composer

Guided authoring surface for purpose, inputs, outputs, policies, tools, and authority; produces skill package artifacts.

Skill Compiler

Generates compiled prompt packages from skill, ontology, policy, tools, memory, and case context; stores hashes for replay.

Ontology Runtime

Abstracts SAP/Ariba/BlackLine tables into enterprise objects such as Invoice, Supplier, Payment, Journal, Contract, Cost Center.

Tool Runtime

Keeps deterministic execution in code: exact invoice matching, aging, credit note creation, payment block, journal posting simulation.

Enterprise Memory Runtime

Stores episodic, pattern, organizational, and learning memory with governance around what can auto-apply.

Policy Runtime

Prevents the agent from violating approval, SoD, DofA, payment, credit, tax, close, or write-back rules.

Learning Runtime

Turns supervisor feedback and outcomes into context/pattern improvements, while routing skill/policy evolution for approval.

Runtime Trace Viewer

Shows skill, context, memory, tool calls, policy checks, decision, evidence, cost, latency, and replay.

Learning model

Finance learning must be explicit. Context and patterns can improve continuously; skill and policy evolution must be governed.

Learning level	Example	Governance stance
Context learning	Supplier X frequently sends duplicate invoices	Safe to auto-apply as memory/context.
Pattern learning	Bank account + amount match predicts duplicates even when invoice number differs	Auto-apply within approved scoring model; monitor drift.
Skill evolution	Add supplier parent-child hierarchy check to duplicate skill	Requires supervisor/process-owner approval and versioning.
Policy evolution	Change payment block threshold or DofA rule	Never automatic; requires governed policy workflow.
Tool creation	Generate find_supplier_hierarchy_match()	Engineering/security review before production use.

Example: Duplicate invoice mission

The duplicate capability demonstrates the intended SBAR model today: the agent and skill are separate governed surfaces, but both reuse deterministic duplicate matching logic.

1

Task

Investigate invoice before payment release.

2

Skill

Duplicate Detection Skill defines what to consider and what output must be produced.

3

Ontology

Runtime works with Invoice, Supplier, Payment, PO, Bank Account instead of SAP table names.

4

Tools

find_duplicate_invoice_candidates() and score_invoice_pair() run deterministic checks.

5

Decision

Confidence 96%; recommend block payment and request supplier confirmation.

6

Evidence

Invoice pair, supplier, amount, PO, bank, payment history, matched fields, evidence hash.

7

Governance

Human approval required before write-back; replay captures why and who approved.

Current implementation anchor: DuplicateLeakageAgent and finance.p2p.duplicate_invoice_detection both use duplicate_invoice_matcher.py. That is the pattern to replicate for high-value skills.

Implementation roadmap

Phase	Build	Outcome
Phase 1	Formalize SBAR control plane	Skill section, Skill Reality Control Plane, Skill-Based Agent Runtime page, duplicate capability proof.
Phase 2	Skill Composer + Tool Registry	Authoring workflow, tool contracts, latency/cost/reliability, deterministic tool catalog.
Phase 3	Ontology + Memory runtime	Enterprise object abstraction, episodic/pattern/organizational/learning memory viewers.
Phase 4	Learning queue + governance console	Proposed skill improvements, policy-change routing, approval, versioning, rollback.
Phase 5	Mission rollout	P2P, O2C, R2R, FP&A, Treasury, Tax, Controls, Continuous Close agents share the same runtime.

Check skill readiness Open Skill Composer path

Skill-Based Agent Runtime

Skill-Based Agent Runtime turns agents from bespoke workers into governed enterprise capabilities.

Why this is not Agent Builder alone

Bespoke-agent problem

SBAR answer

Architecture

Skill compiler and compiled prompt packages

Editable source of truth

Generated runtime artifact

Compiled prompt example: Duplicate Invoice Detection

Core platform components

Skill Runtime

Skill Composer

Skill Compiler

Ontology Runtime

Tool Runtime

Enterprise Memory Runtime

Policy Runtime

Learning Runtime

Runtime Trace Viewer

Learning model

Example: Duplicate invoice mission

Implementation roadmap