Using raia Agents in the AI Development Lifecycle

It's tempting to treat AI adoption as a coding-speed problem. Software delivery is a system, not a coding task. Requirements → design → build → test → release → operate: value depends on the whole chain, and end-to-end throughput is governed by the slowest constraint. Speeding up the "build" box alone just moves the queue — bigger review loads, more test pressure, less stable releases.

The hidden tax in most delivery systems is waiting caused by fragmented context:

A developer implementing refund logic today has three options: read a possibly stale wiki, interrupt a human expert, or guess. All three are failure modes we've normalized. The fix isn't faster typing — it's connected knowledge.

Look at where the knowledge actually lives. What the PM knows lives in vector stores. What the codebase knows lives in git. Neither learns from the other automatically, and the cost shows up every week: interrupt-driven experts, support that lags releases, documentation that's perpetually behind, and new hires taking months to absorb tribal knowledge.

Don't ask one model to be both the engineer and the librarian. The coding agent is the execution model: its context is the repo, the diff, and the session. raia agents are the knowledge model: each searches a knowledge base built from thousands of your documents, and its fixed instructions make every answer grounded, cited, and repeatable.

• More knowledge than a session can hold — Retrieval runs over the entire knowledge base; only the relevant, already-summarized answer enters the coding session.
• Predictable by design — The agent's instructions don't vary by session or developer. The same question gets the same sourced answer, every time.
• Each side does what it's best at — Code truth stays in git with the coding agent. Business truth stays managed in raia. Neither crowds out the other.

Delegation fails at both extremes. Too big — "build an e-commerce platform" — produces thousands of unreviewed lines. Too small — "write this one function" — barely saves time. The right size is a clear goal with clear limits: a small, well-defined task with a written spec, the right knowledge on tap via raia, automated checks, and a human sign-off.

Four connections tie raia to your dev toolchain. MCP — the Model Context Protocol — is the open standard that lets AI tools call other systems securely.

1. 01

   In every session (live today)

   The coding agent asks, raia answers, via MCP. raia exposes each agent as a callable tool, so a coding session can query the Product or Codebase Agent mid-plan or mid-build and get a sourced answer back.

2. 02

   After every merge (live today)

   CI sends updated docs into raia's knowledge bases. When a pull request merges, a CI job routes the changed Markdown — specs, ADRs, user docs — to the right agent's knowledge base. This is the wire that closes the loop.

3. 03

   For status questions (next)

   raia reads GitHub and Jira (read-only) so PMs can ask "what shipped this week?" in Copilot or Teams and get a live answer.

4. 04

   On events (next)

   Escalations and merges trigger automations in both directions — for example, a bug-shaped Live Chat escalation becomes a structured GitHub issue.

Here is what the loop looks like for a single feature, and exactly when the coding agent references the raia agents.

1. 01

   Pick up the task

   A developer opens a coding-agent session on the ticket. raia is already standing by, trained on your specs, ADRs, and help docs.

2. 02

   Plan it

   Before writing code, the coding agent asks raia: "what should this do?" goes to the Product Agent; "how does it work today?" goes to the Codebase Agent. The plan the developer reviews cites both — including constraints the developer didn't personally know.

3. 03

   Build it

   Mid-task questions get answered without leaving the session: "what's the refund window for annual plans?" → the Product Agent returns the policy, with the source document cited. No interrupted expert, no stale wiki, no guessing.

4. 04

   Check it

   Before merge, an automated review step summarizes the diff's behavior changes and asks the Product Agent whether it matches the agreed spec. Confirmed mismatches land as PR comments — caught at review time, not in UAT.

5. 05

   Merge it

   The flow reverses. CI sends the updated docs to raia, all three agents learn the change, and support can answer questions about the feature the day it ships.

Three agents cover the entire lifecycle. Build each in Launch Pad (including its fixed instructions), train it in raia Command, expose it with the MCP Skill, and supervise its quality in Copilot.

Train them on documents you already have — this is the one-time investment, and it's measured in days. Later, you can front all three with raia's Orchestrator Skill so callers need only one endpoint and one key; don't block the rollout on it.

The playbook repository is the setup process. Each step is backed by a drop-in template.

{
  "mcpServers": {
    "raia-product": {
      "type": "http",
      "url": "https://api.raia2.com/mcp",
      "headers": { "Authorization": "${RAIA_MCP_KEY}" }
    }
  }
}

cd examples/golden-path
npm test
npm run dry-run

The raia agents work best when they behave like a reliable answer service, not a chat partner. The instructions control how the agent answers; the knowledge base controls what it knows. Both are versioned, reviewed, and owned.

The minimum operating loop has seven steps. Here is exactly who engages which agent at each one.

Beyond the minimum loop, the playbook defines twelve repeatable plays. Start with four — A2, A4, C1, and B1 — in a single repository, and adopt the rest as the loop proves out.

Present this before anyone asks. Four rails keep the system safe.

1. 01

   Scoped keys, rotated

   Per-agent keys live in environment variables and CI secrets, never in committed files. A leak affects one agent; rotation is one click in Launch Pad.

2. 02

   Read-only by default

   Conversational agents get read tools only. Write access lives in audited automations — and every write path is proven in dry-run mode before it's enabled.

3. 03

   Customer data stays governed

   PII remains in raia's stores, with retention controls and immutable logs. Coding sessions receive synthesized answers, never raw transcripts.

4. 04

   Humans gate every merge

   Automation drafts pull requests; it never merges them. The allowlisted class of auto-drafted fixes grows only as its human-approved merge rate proves out.

Measure outcomes, not generated output. Retire "lines of code generated" as a KPI and adopt the question: are we delivering better software faster, with less risk and less friction?

Capture a baseline before setting targets, and commit to a day-90 review: widen the plays that moved their metric, and kill the ones that didn't.

These are review horizons, not permission deadlines — a team advances only when the current stage's evidence is complete.

Everything referenced in this guide ships in the public playbook repository.

• templates/ — drop-in .mcp.json, CLAUDE.md / AGENTS.md snippets, IDE configs, pilot brief, and scorecard
• skills/spec-review/ — the spec-aware review gate for Claude Code
• workflows/knowledge-refresh.yml — the fail-closed, plan-first knowledge-refresh reference
• examples/golden-path/ — the credential-free, executable end-to-end reference
• docs/quick-starts.md — first-session actions and stop conditions for each role
• docs/governance.md — the full control, metric, and maturity frameworks

Every merge makes the whole company smarter.