Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/telivityai/otaip/agent-boundariesgit clone --depth 1 https://github.com/TelivityAI/otaipWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.03256 |
| Opus 5 | $0.00000 | $0.01628 |
| Sonnet 5 | $0.00000 | $0.00651 |
| Haiku 4.5 | $0.00000 | $0.00326 |
Grade A, and why
agent-boundaries scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 142 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent Boundaries
Many OTAIP stages contain sibling agents with adjacent responsibilities. This guide states which agent owns which responsibility — the intent, field, or operation that assigns a request to exactly one agent — derived from the agent contracts.
Use it to assign a request to the right agent: find the relevant agents, and the
Boundary line is the deciding signal. Each agent is identified by its readonly id
(the binding identifier).
Scope note: every boundary here is derived from the agents' own contracts in
packages/. When a contract is genuinely ambiguous it is called out inline.
Orchestration vs. single-purpose — Agent 9.1
This one ownership rule covers the most agents. 9.1 Orchestrator owns a request only
when it requires a multi-step, multi-agent workflow — its contract defines exactly these
pipelines: search-to-price, book-to-ticket, full booking, exchange flow,
refund flow (with conditional/parallel steps and error handling). A single concrete
operation belongs to its specific agent, never 9.1.
| Belongs to 9.1 (multi-step) | Belongs to the specific agent (single op) |
|---|---|
| "search → price → book → ticket this end to end" | one availability query → 1.1 |
| "reconcile, then refund, then update loyalty" | one BSP reconciliation → 7.1 |
| "run the exchange flow (assess + reissue + collect)" | one pre-ticket audit → 6.2 |
| any chain that hands output between ≥2 agents | profile read / apply-to-PNR → 8.1 |
| mid-office PNR QC / deadline scan → 8.3 |
Note: an agent that internally composes others is not automatically 9.1. For example 5.5 Self-Service Rebooking composes 1.1 + 5.1, but it is a single named capability ("present priced rebooking alternatives") — still 5.5, not 9.1. The 9.1 signal is the user asking for a multi-stage pipeline, not an agent happening to call others.
Reference data (0.x)
| Pair | A | B | Boundary |
|---|---|---|---|
| 0.1 ↔ 0.6 | 0.1 Airport/City Code Resolver — IATA/ICAO airport & city codes, multi-airport cities | 0.6 Currency & Tax Code Resolver — ISO 4217 currency + IATA tax/surcharge codes | A resolves a place code; B resolves a money/tax code |
| 0.3 ↔ 0.6 | 0.3 Fare Basis Code Decoder — decodes fare basis into cabin, restrictions, advance-purchase, penalties | 0.6 Currency & Tax Code Resolver | A decodes a fare basis; B resolves a currency/tax code |
| 0.3 ↔ 3.3 | 0.3 Fare Basis Code Decoder | 3.3 PNR Validation — pre-ticketing PNR checks | A decodes a code; B validates a PNR |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 142 lines · 0 tokens per session scan A 5e21c9894dae
agent-boundaries is an agent published in the GitHub repository TelivityAI/otaip (40 stars, last pushed 9d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 3,256 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
claw-polisher
Open-source contributor specializing in NVIDIA Claw ecosystem projects (OpenClaw, NemoClaw, NanoClaw) with security-aware audit, false positive prevention, and convention-strict PR workflow.
framework-scout
Open-source agent framework assessor that evaluates community health, supersession risk, architecture alignment, and governance sustainability to classify investment readiness before committing resources.
marketing-claw-playbook
This playbook lets an external claw act as FlowWink's marketing department — running paid growth, content, audience research, and reporting end-to-end.
agent_invite
The onboarding text handed to an external agent that will operate a FlowWink instance over MCP — connection, protocols, resources and cadence.
finance-claw-playbook
This playbook lets an external claw act as FlowWink's finance department — running invoicing, expense booking, bank reconciliation, and period close (record-to-report) — without…
operations-claw-playbook
This playbook lets an external claw act as FlowWink's operations department — running inventory, purchasing, order fulfillment, manufacturing, and field service — without FlowPi…