V1 Agent Platform

What this agent does

This one isn't an agent — it's the runway every agent lands on. One repo where every agent's code and config live, one pod pattern for how agents run and deploy, and the platform decisions (models, tooling, access, logging) made once so every subsequent build inherits them instead of re-deciding them. The first two production agents (content creation, Snowflake reporting) ship on it in the same month, which is the point: the platform is proven by carrying real agents, not by existing.

Why this agent

• Six builds in 90 days only works with shared rails — without the platform, each agent re-solves hosting, access, logging, and review from scratch, and M2/M3 slip.
• The owner rule needs the audit trail — "every agent owned and managed like a product" requires being able to see what an agent did and why; the log is a platform feature, not per-agent homework.
• Governance lands in V3 — cost controls and governance arrive program-wide in Month 3; they bolt onto this platform. Building agents off-platform now creates migration debt in November.
• Redis-owned by design — Verto's engineer builds inside it (SOW §3.7), but the platform and standards are Redis's (Keith + Josh via MOps), so the capability survives any contractor transition.

Trigger & inputs

• Trigger — M1 kickoff; platform decisions are the first deliverable, before any agent code.
• Reads — the 79-agent catalog (what the platform must eventually carry), the two M1 agent briefs (what it must carry now), and the contractor security protocol (individual accounts + Okta, no shared logins).
• Context — existing Redis infrastructure and tooling; the SOW's constraint that workflows run on Redis's own technology and team.

What it produces

• The repo — every agent versioned in one place, reviewable like any codebase.
• The pod pattern — a standard way an agent runs, deploys, and is monitored.
• Platform decisions, written down — models, tooling, access patterns, logging standards; decided once, inherited by every build.
• The audit trail — per-agent logs any owner can read without asking an engineer.

How it works

• Decide: models, hosting, tooling, and access patterns — documented as the platform decisions.
• Stand up: the repo and the first pods.
• Prove: both M1 agents built on it, not beside it.
• Operate: the platform is standing infrastructure from October; changes are versioned like any product.

Guardrails & human-in-the-loop

• Access — every agent gets individual credentials via Okta per the security protocol; no shared logins, no scraped sessions.
• Never-do list — no agent ships outside the repo/pod pattern; no production access without its brief's guardrails implemented.
• Thresholds — cost visibility from day one even though formal cost controls land in V3; anomalous spend pages the platform owners.
• Escalation — platform-level failures stop the agents that ride it; better a paused agent than an unaudited one.

Success metrics

• North star — both M1 agents live on the platform by end of September.
• Quality bar — a new agent's platform work (hosting, access, logging) measured in days, not weeks, by M2.
• Guardrail metric — zero agents running outside the pattern; zero shared credentials.
• Hours returned — indirect: measured through the agents it carries, on the program's hours-returned ledger.

Build plan

• V0 · Decisions (early Sep) — platform choices documented and agreed; Lachezar onboarded Sep 1. Exit: decisions signed off by Keith + Josh.
• V1 · Carrying agents (Sep) — repo + pods live, both M1 agents running on them. Exit: content + reporting agents in production on the platform.
• V2 · Program scale (Oct–Nov) — M2/M3 agents added; V3 wave bolts on cost controls and governance. The platform stays boring on purpose.

Dependencies & risks

• Verto onboarding Sep 1 — the engineer's access (individual account, Okta) must be ready day one or M1 compresses.
• Decisions before code — if agent builds start before platform decisions land, the repo becomes archaeology by October.
• Ops & reporting ownership TBD — the platform can log everything, but the daily-owner rule still needs names on the agents it carries. [owner to complete]