Agent-Ready CTO

Status: Capability catalog at 8 offerings; Phase 2 engagement/safety policy locked; Phase 3 discovery layer built. Repo prepared and committed locally — one manual push away from public (see docs/discoverability-strategy.md Section 5).

This project builds on agent-kernel — Filip's reusable skills/prompts/templates library — rather than reinventing its patterns. See docs/injection-guide.md in agent-kernel for how to formally inject it here (git submodule) once build work starts in Phase 3.

Important context discovered during capability review: Filip has a larger existing live ecosystem beyond agent-kernel — digital-twin-filip (4 already-built roles), agent-factory (a real HITL-governed agent runtime), digital-twin-factory (public demo portal, live at apps.solidcage.com), and operational-intelligence-lab (an already-priced cohort program with a deployed tracker app). Several catalog capabilities were built directly from that ecosystem rather than from scratch. See docs/proposed-capabilities-assessment.md for the full picture — there's still an open question of whether Phase 3 should link/repackage that ecosystem rather than rebuild pieces of it.

What this is

A structured, machine-legible profile and capability catalog positioning Filip as senior technical/executive judgment that other people's AI agents (acting on behalf of real, accountable humans and companies) can discover, evaluate, and route requests to — alongside normal human-driven channels like referrals and LinkedIn.

Core commitment, disclosed on every offering: Filip uses agent-kernel to accelerate research, analysis, and drafting — but every deliverable is personally reviewed and every engagement includes a real, live human touchpoint delivered by Filip. Whoever is on the other end of a request (human or agent-mediated) is guaranteed direct contact with the actual person, never a bot standing in. See docs/delivery-model.md. One capability (mission-critical-unblock.yaml) extends that guarantee to Filip's own hands-on technical execution — see docs/technical-range.md.

Safety commitment: every engagement goes through tiered verification, a hard deposit gate, and defined stop conditions before and during work — see docs/engagement-safety-policy.md.

Where things stand

• Phase 0 — Idea validated using agent-kernel's idea-evaluator and red-team-idea-validation skills. Verdict: 🟡 Promising (67/90), Go with conditions. (docs/idea-evaluator-scorecard.md, docs/red-team-validation.md)
• Phase 1 — Initial capability model locked: 5 offerings, each with explicit inputs/outputs/turnaround/pricing and a mandatory delivery_model block.
• Phase 1b — Assessed 4 proposed new capabilities, resolved scope with Filip. Added engineering-velocity-optimization.yaml and agentic-first-train-the-trainer-inhouse.yaml; dropped/held the other two. (docs/proposed-capabilities-assessment.md)
• Phase 1c — Conative profile closed out using Filip's actual Kolbe A™ Index (MO 7-6-5-2), layered with his own operating-philosophy, client-fit, and escalation input. (docs/conative-profile.md)
• Phase 1d — Added the hands-on technical evidence layer and a new capability, mission-critical-unblock.yaml, built on agent-kernel's firefighter and shake-the-box skills. (docs/technical-range.md)
• Phase 2 — Engagement & safety policy drafted using governance-hierarchy-design + hitl-and-guardrails. Covers: 3-tier verification (live call + LinkedIn + corporate email, scaling up to authority-to-spend confirmation and named executive sponsor tracking), payment mechanics (ACH/Venmo, no checks, Stripe planned), capacity/rush-pricing for urgent blockers, hard decline criteria (pure marketing companies, financially distressed startups), three distinct stop conditions (non-payment, executive sponsor departure, mid-engagement red flag) each with its own refund treatment, and a confidentiality/data-retention default pending confirmation. (docs/engagement-safety-policy.md)
  • Drafted first-pass SOW (legal/sow-template.md) and NDA (legal/nda-template.md) templates, contracting entity Solid Cage Inc. Both are explicitly marked as unreviewed drafts — Filip has existing reference materials to reconcile with these, and both need attorney review before use with a real client.
  • Every capabilities/*.yaml file now carries hitl.verification_tier and hitl.payment_methods_accepted; Tier 3 capabilities also carry executive_sponsor_tracking_required.
  • Review SLA confirmed: every inbound request is reviewed within 2 business days, regardless of an urgency label. Priority scheduling for a confirmed, paying crisis engagement applies only to new-work queue order — existing client engagements are never interrupted to accommodate it.
  • Confidentiality data-retention period confirmed at 180 days post-engagement-close. Stripe integration confirmed as TBD — manual ACH/Venmo payment stands until it's set up.
• Phase 3 — Standalone repo confirmed (not merged into digital-twin-factory/agent-factory). Built the machine-first discovery layer: capabilities.json (compiled catalog), .well-known/agent-card.json (A2A-compatible), llms.txt, a minimal schema.org-tagged index.html (deliberately not a marketing site), and a working mcp-server/ (MCP, runs locally today). Full rationale, honest maturity caveats per layer, distribution copy, and exact manual push/Pages-enable steps: docs/discoverability-strategy.md.
  • Not yet done: the repo isn't pushed to GitHub yet — this session can't push (no credentials, and the local sandbox that edits these files has no network access). docs/discoverability-strategy.md Section 5 has the exact commands to run once, from your own machine.
  • Not yet done: the MCP server isn't hosted publicly — code is complete and runs locally; going live needs you to pick a host (Render/Railway/Fly.io) — see mcp-server/README.md.
• Phase 4 — Package as a solution-review-package (review-summary, gap-analysis, implementation-plan, evaluation-plan).
• Phase 5 (later, only once there's real signal) — live-host the MCP server and flip the A2A agent card to a real endpoint, x402 payments, marketplace/directory distribution.

Key conditions coming out of validation

1. Content before protocol. Ship the structured catalog and a working request/pay path before any MCP/A2A/payment-protocol infrastructure.
2. Reuse what already exists — agent-kernel and the wider twin ecosystem — don't rebuild it.
3. Hard-gate safety, don't just document it. Verification tier, deposit, and stop conditions are literal fields in every capability spec, backed by docs/engagement-safety-policy.md.
4. Disclose the AI/human split on every offering, not just in a trust section. See docs/delivery-model.md.
5. Get a real distribution signal within 30 days through manual channels — don't wait passively for agent crawlers to find this.
6. Keep the catalog tight. Don't stack every proposed capability as a new line item — combine or narrow where needed.
7. Escalate on hazy objectives, not just risk. The latter always routes to Filip — see docs/conative-profile.md.
8. Keep the AI twin's guardrails and Filip's personal capability distinct. See docs/technical-range.md.
9. Three stop conditions, three different resolutions. Non-payment, sponsor departure, and a mid-engagement red flag are not the same event and don't get the same refund treatment — see docs/engagement-safety-policy.md Section 5.

Repository structure

agent-ready-cto/
├── README.md                                    ← you are here
├── index.html                                   ← Phase 3: minimal schema.org-tagged hub page (not a marketing site)
├── llms.txt                                     ← Phase 3: structured entry point for LLMs/agents
├── capabilities.json                            ← Phase 3: compiled machine-readable catalog
├── .well-known/
│   └── agent-card.json                          ← Phase 3: A2A-compatible agent card (discovery-only today)
├── mcp-server/                                  ← Phase 3: MCP server (runs locally today; see mcp-server/README.md to host it)
│   ├── package.json
│   ├── server.js
│   └── README.md
├── docs/
│   ├── idea-evaluator-scorecard.md              ← Phase 0
│   ├── red-team-validation.md                   ← Phase 0
│   ├── delivery-model.md                        ← Phase 1: AI/human disclosure principle
│   ├── capabilities-summary.md                  ← human-readable catalog (8 offerings)
│   ├── proposed-capabilities-assessment.md      ← Phase 1b: new capability merit review + resolution
│   ├── conative-profile.md                      ← Phase 1c: operating system behind the twin
│   ├── technical-range.md                       ← Phase 1d: hands-on technical evidence layer
│   ├── engagement-safety-policy.md              ← Phase 2: verification, payment, decline, stop conditions
│   └── discoverability-strategy.md              ← Phase 3: full proposal, caveats, distribution copy, go-live steps
├── legal/
│   ├── sow-template.md                          ← Phase 2: draft, unreviewed, pending Filip's materials + counsel
│   └── nda-template.md                          ← Phase 2: draft, unreviewed, pending Filip's materials + counsel
└── capabilities/                                ← machine-readable capability specs
    ├── cto-decision-call.yaml
    ├── ai-architecture-review.yaml
    ├── engineering-velocity-optimization.yaml
    ├── product-rescue-assessment.yaml
    ├── mission-critical-unblock.yaml
    ├── agentic-engineering-workshop.yaml
    ├── agentic-first-train-the-trainer-inhouse.yaml
    └── technical-due-diligence.yaml