Talon Persona Guides
This guide describes how different roles in your organization use Talon: what they care about, which commands they run, and how policy configuration affects them. Day to day, DevOps, FinOps, and engineering leadership use Talon to operate AI use cases — cost control, reliability, shared policy, and session understanding — while compliance and security roles consume the signed evidence those operations produce as a cross-cutting proof layer.
Who Uses Talon?
| Persona | Primary goal | Typical tasks |
|---|---|---|
| DevOps Engineer | Get agents running and keep them healthy | Install, init, run, validate, serve |
| FinOps Engineer | Cost control and budget compliance | Costs, budgets, model routing, export for analysis |
| CTO / Head of Engineering | Oversight, costs, and governance posture | Costs, report, memory health, config |
| SecOps / Security Officer | Secrets, PII, injection prevention, policy enforcement | Secrets vault, audit, PII tiers, budget denial |
| Compliance Officer | Prove processing records and regulatory readiness | Audit trail, exports, verification, reports |
DevOps Engineer
What they care about: Getting Talon installed, initializing projects, running agents with policy enforcement, and validating configuration. They need a smooth path from zero to a working governed agent.
Key commands
Use talon run (not talon alone) to run an agent; flags like --attach go after run, and the prompt is the last argument: talon run [flags] "your prompt".
# Install and bootstrap
make build # or: go install .../cmd/talon@latest
talon init # Interactive wizard (in terminal); or:
talon init --scaffold --name my-agent --owner dev@co.at # Non-interactive: create agent.talon.yaml + talon.config.yaml
talon validate # Check policy is valid
talon validate --strict # Strict compliance check
# Run agents (subcommand is always "run"; prompt is the final quoted argument)
talon run "Summarize EU AI regulation trends" # Real run with LLM
talon run --dry-run "What is revenue?" # Policy check only, no LLM call
talon run --attach report.pdf "Summarize this document" # Attachments (injection-scanned)
talon run --tenant acme --agent sales-bot "Your prompt here" # Multi-tenant
# Serve (triggers, webhooks, cron)
talon serve --port 8080
Workflow example
- Clone repo,
make build, thencd my-project && talon init(wizard) ortalon init --scaffoldfor quick defaults. - Set LLM key:
export OPENAI_API_KEY=sk-...ortalon secrets set openai-api-key "sk-...". talon validateto confirm policy loads.talon run "First query"to run with real LLM; check evidence withtalon audit list.- For production: store keys in vault, set
TALON_DATA_DIRand crypto keys, thentalon serve. For project-scoped onboarding or evaluation (e.g. trying Talon in a repo without touching~/.talon), useTALON_DATA_DIR=$(pwd)/.talonso vault and evidence DBs live under the project directory.
Policy configuration that matters
agent.name,agent.version— Identity and versioning. When you run without--agent, the runtime agent ID (evidence, memory) is taken fromagent.namein the loaded policy.policies.cost_limits— Per-request, daily, monthly (DevOps often sets these with FinOps).policies.model_routing— Tier 0/1/2 models; Tier 2 may require Bedrock for EU-only.triggers— Cron and webhooks if usingtalon serve.
Compliance Officer
What they care about: GDPR Article 30 processing records, NIS2 incident evidence, EU AI Act transparency, and tamper-evident audit trails. They need to export evidence, verify integrity, and produce reports for auditors or regulators.
Key commands
# List and inspect evidence
talon audit list --limit 20 # Recent evidence records
talon audit list --tenant acme # Filter by tenant (multi-tenant isolation)
talon audit show <evidence-id> # Full record: HMAC, PII, tiers, policy reasons
talon audit verify <evidence-id> # Verify HMAC-SHA256 signature
# Export for regulators
talon audit export --format csv --from 2026-02-01 --to 2026-02-28
talon audit export --format json --limit 1000
# Summary and reporting
talon report # Compliance summary (counts, cost)
talon report --tenant acme # Per-tenant summary
Workflow example
- Monthly GDPR Art. 30: Run
talon audit export --format csv --from ... --to ...and attach to processing records. - Incident review: Use
talon audit listto find the time window, thentalon audit show <id>for full classification, PII detected, and policy decision. - Integrity check: Run
talon audit verify <id>on sampled evidence to confirm HMAC-SHA256 intact. - Board/auditor summary: Use
talon reportand optionallytalon report --tenant <id>for per-tenant posture.
Policy configuration that matters
compliance.frameworks— Declared frameworks (e.g. gdpr, eu-ai-act, nis2).compliance.data_residency— e.g.eu.audit.retention_days,audit.log_level— How long evidence is kept and how detailed.policies.data_classification— Input/output scan, PII handling; affects what appears in evidence.
CTO / Head of Engineering
What they care about: Strategic oversight: cost visibility, multi-tenant isolation, agent health, and governance posture. They want a single view of “how are we doing?” without running low-level audit queries.
Key commands
# Cost and posture
talon costs # Cost by tenant/agent (today + month)
talon costs --tenant acme # Per-tenant cost breakdown
talon costs --agent sales-bot # Per-agent cost
talon report # Compliance summary (evidence count, cost)
talon report --tenant acme
# Agent memory and health
talon memory list --agent sales-analyst # Memory entries for an agent
talon memory health --agent sales-analyst # Trust distribution, conflicts
talon memory audit # Evidence chain for memory
# Configuration and validation
talon config show # Resolved config (data dir, keys, DBs)
talon validate --strict # Policy and compliance check
talon version # Binary version and build info
Workflow example
- Weekly review: Run
talon costsandtalon reportto see spend and evidence volume per tenant. - New agent rollout: After enabling memory in policy, use
talon memory health --agent <name>to monitor trust and conflicts. - Pre-audit: Run
talon validate --strictandtalon config showto confirm policy and environment.
Policy configuration that matters
policies.cost_limits— Daily/monthly caps; CTO cares that they align with budget.agent.model_tier— Default tier for the agent.memory— Memory is off by default; enable it in policy (see MEMORY_GOVERNANCE.md) formemory list/memory healthto show data. If enabled, CTO may trackmemory healthand rollback when needed.
SecOps / Security Officer
What they care about: Secrets management, PII handling, prompt-injection prevention, and policy enforcement (e.g. budget denials). They need to see who accessed which secrets, that PII drives model tiering, and that injections are detected and optionally blocked.