How Thomas, The Strategic CTO, Uses WayOfTeams

A step-by-step walkthrough of how a CTO evaluates, deploys, and governs WayOfTeams as the strategic AI platform that balances innovation, security, cost control, and competitive advantage.

Who Thomas Is

Thomas is responsible for the entire technology architecture, engineering organization, and digital roadmap. He does not get excited about AI demos. He asks: "Does this reduce risk, lower operational costs, or significantly increase our product's value?" If the answer is not clearly yes, he does not approve the spend.

He balances cloud API models against self-hosted local LLMs. He governs company-wide AI adoption. He ensures employees can use AI without exposing proprietary code or database credentials. He bridges the gap between what engineering wants and what the board approves.

He has seen three AI initiatives fail at previous companies. One leaked training data. One blew out the API budget in a month. One produced code that nobody could maintain because nobody understood what the AI built. He learned from all three. AI is a strategic lever. It needs strategic governance.

Phase 1: Vendor Evaluation (Before He Signs Up)

What Thomas Does

Thomas evaluates vendors before signing up. He asks questions that determine whether WayOfTeams survives procurement. This process takes him two to four weeks for any new platform.

Security and data governance:

  • Does model input leave the tenant boundary? If an engineer in Company A asks the AI about their code, does Company B's data ever touch it?
  • Is there a data processing agreement (DPA) available? His legal team requires one before any vendor processes company data.
  • Can he pin tenant data to specific regions for GDPR compliance? His European office requires EU-only data residency.
  • Are there SOC 2 Type II or ISO 27001 certifications? His CISO will not approve without them.
  • How are API keys and secrets stored? Can they be masked at the proxy layer so AI tools never see raw credentials?

Vendor lock-in:

  • Can he export all data? Tickets, plans, knowledge, rules, standups? If he cancels tomorrow, does he lose everything?
  • Is the f-rr-d system Git-backed and portable? Yes. He can clone the repo and run it anywhere. This is a hard requirement.
  • Can he self-host or migrate to another platform if the vendor fails? The Git-backed architecture means his data survives the vendor.

SLA and reliability:

  • What uptime guarantees exist? 99.9%? 99.99%? What are the penalties for missing the SLA?
  • What is the disaster recovery plan? RPO and RTO targets?
  • Is there a read-only fallback if the primary instance goes down?

Cost model:

  • Per-seat pricing or usage-based? He prefers per-seat for predictability.
  • Does AI inference cost extra? Is there a token budget? Can he set spending caps per team or per developer?
  • What happens when usage scales? Does the cost model break at 100 developers? 500?

WayOfTeams survives because it is Git-backed, tenant-isolated, and does not lock his data into a proprietary format. The f-rr-d repo is his exit strategy.

What He Checks

  • Data isolation between tenants
  • Data portability and exit strategy
  • Compliance certifications
  • Cost predictability at scale

Why This Works for Thomas

He has been burned by tools that look great in a demo but cannot survive production scrutiny. WayOfTeams passes the architecture check: BEAM for concurrency, Postgres for isolation, Oban for reliability, OTel for observability. The foundation is solid.

Phase 2: Controlled Pilot (Week 1)

What Thomas Does

Thomas does not roll out AI to everyone. He runs a controlled pilot with his most experienced team. Three to five developers who already use AI tools daily. This is deliberate: he wants the pilot to succeed, and experienced developers are more likely to produce good results.

Success criteria (set before pilot starts):

  • Ticket throughput increases by at least 20%
  • Code quality does not degrade (measured by review queue rejection rate)
  • No data leakage incidents
  • Developer satisfaction score above 7 out of 10
  • Cost per developer stays within budget

What he configures during the pilot:

  • Company settings: project prefix, ticket namespace
  • Roles: Developer for the pilot team, Viewer for stakeholders
  • Entitlements: pilot team gets full access, everyone else gets nothing
  • Knowledge base: pre-load architectural decisions and coding standards
  • Rules: enforce naming conventions, module boundaries, and API usage
  • Review queue: all AI-generated code requires lead approval

What he measures weekly:

  • Tickets created and completed per week
  • Plan generation and implementation success rate
  • Time from ticket creation to merge
  • Review queue rejection rate
  • Developer feedback (weekly anonymous survey)
  • Cost per developer per week
  • Token consumption by task type

What he discovers during the pilot:

  • Developers use AI more for test generation than code writing
  • The review queue catches 3 issues in the first week
  • One developer asks for a rule preventing AI from modifying config files
  • Cost per developer is $45 per month, well under his $100 budget

After four weeks he presents to the board: "20% throughput increase, zero data incidents, $45 cost per developer per month. Recommendation: expand to two more teams."

He asks the AI during the pilot:

"What is the average cost per developer this week?"

The AI returns: "$45.23. Breakdown: 62% local inference (zero API cost), 38% cloud API calls. Most cloud spend is on plan generation and code review tasks."

He asks:

"Which developers are using AI the most?"

The AI returns a list with ticket counts and token consumption. He sees that the two most productive developers are also the highest consumers. The correlation is clear: more AI usage, more output.

What He Sees

  • Measurable throughput improvement
  • Zero data incidents
  • Cost well within budget
  • Developer satisfaction above threshold
  • Clear recommendation for expansion

Why This Works for Thomas

He does not approve spending based on demos. He approves based on metrics. The pilot gives him four weeks of data with clear success criteria. The numbers speak for themselves.

Phase 3: Security and Access Control (Week 1–2)

What Thomas Does

Thomas locks down the platform before expanding beyond the pilot.

Data governance:

  • Every MCP call carries a JWT with tenant isolation. Cross-tenant reads are impossible at the database layer. He verifies this by testing: can Developer A from Company X read Company Y tickets? No.
  • Private boards are invisible to everyone except the owner. Not just hidden. Truly invisible. He tests this.

Secret management:

  • API keys for AI providers are stored in environment variables, not in code or config files. He verifies by grepping the codebase.
  • External calls use Wayofteams.Http.fetch_url, not raw :httpc. TLS cert chain handling is built in.
  • He configures a secret-masking proxy layer so AI tools never see database credentials or internal service URLs.

Access control:

  • RBAC via the role hierarchy: Superadmin, Admin, Lead, Developer, Viewer. Each role has clear permissions.
  • Board-level permissions: owner, admin, member, viewer.
  • MCP-level permissions: every tool call is authenticated and tenant- scoped.
  • Coordinator role: cannot write code. Track, verify, deploy only.

Audit trail:

  • mcp_audit logs every tool call with who, when, what, and outcome.
  • Agent Ops tracks agent invocations, success rates, and HITL compliance.
  • f-rr-d provides Git-backed change history for every decision.

He presents the security posture to his CISO. The CISO reviews the JWT isolation, the RBAC model, the audit trail, and the secret management. It holds up. Thomas gets sign-off to expand.

What He Sees

  • Tenant isolation verified at database layer
  • Secret management audited and clean
  • RBAC model documented for CISO
  • Complete audit trail for every action

Why This Works for Thomas

Security is not optional. It is the price of admission. WayOfTeams gives him the controls and the evidence to pass CISO review.

Phase 4: Cost Governance (Week 2–3)

What Thomas Does

Thomas monitors AI spend like cloud spend. He has seen AI budgets blow out at previous companies. One team spent $15K in a month on API calls because nobody set quotas.

Task-based model routing:

  • Simple tasks (ticket creation, status updates, standup generation) route to small, cheap models. Cost per task: fractions of a cent.
  • Complex tasks (plan generation, code review, architecture analysis) route to large, capable models. Cost per task: a few cents.
  • He configures the split in config/config.exs and monitors the ratio via mcp_audit.

Local vs cloud inference:

  • LM Studio runs on internal GPU hardware for high-volume, low- complexity tasks. Zero API cost.
  • Ollama handles lightweight models on edge hardware.
  • OpenRouter balances speed, cost, and context size across providers for tasks that need cloud models.

Quota management:

  • Per-developer request quotas: 200 requests per day for the pilot team, 100 for standard users.
  • Per-team token budgets: 5M tokens per month for engineering, 2M for operations.
  • Consumption monitored via mcp_audit and skill reports.

What he tracks monthly:

  • Total AI spend (API costs + inference infrastructure)
  • Cost per developer per month
  • Cost per ticket completed
  • Local vs cloud inference ratio
  • Token consumption by task type
  • Trend: is cost per ticket going up or down?

He presents the AI cost report to the CFO alongside productivity gains. The ROI is clear: $45 per developer per month produces 20% throughput increase. The math works.

He asks the AI:

"What is the trend on cost per ticket over the last 3 months?"

The AI returns: "Cost per ticket dropped from $310 to $230. Main driver: increased local inference ratio. Local inference now handles 62% of tasks, up from 35% in month one."

What He Sees

  • Monthly cost breakdown by team and task type
  • Local vs cloud inference ratio
  • Cost per ticket trend
  • ROI calculation: spend vs throughput gain

Why This Works for Thomas

He has seen AI budgets blow out without visibility. WayOfTeams gives him the granularity to know exactly where every dollar goes and whether it is producing value.

Phase 5: Compliance and Regulatory Readiness (Week 3–4)

What Thomas Does

Thomas is responsible for EU AI Act compliance. The penalties are real: up to 3% of global annual revenue for violations.

EU AI Act readiness:

  • Every AI action is logged and auditable via mcp_audit.
  • HITL layers provide human oversight: Layer 1 Auto for low-risk, Layer 2 Notify for medium-risk, Layer 3 Escalate for high-risk.
  • Tenant isolation ensures data separation between organizations.
  • Version management tracks system changes with rollback capability.

Data protection:

  • Privacy policy covers data collection, usage, sharing, and retention.
  • He configures which knowledge and rules are visible to which teams.
  • Sensitive data can be pinned to specific regions via deployment config.

Code provenance:

  • f-rr-d tracks every change with Git history.
  • Ticket references in code provide traceability from requirement to production.
  • Review queue ensures human approval before AI code reaches production.

What he demonstrates to auditors:

  • "Show me every AI action taken in the last 90 days" -> mcp_audit
  • "Show me that Company A data never touched Company B agents" -> JWT isolation verification
  • "Show me the complete change history for this production system" -> f-rr-d Git log
  • "Show me human approval for every code change" -> review queue audit

The auditor signs off. Thomas has a defensible compliance posture.

What He Sees

  • Complete audit trail for every AI action
  • HITL compliance documented
  • Data isolation verified
  • Human approval chain for every code change

Why This Works for Thomas

Compliance is not a feature. It is a requirement. WayOfTeams gives him the evidence to pass audits without building a custom compliance layer.

Phase 6: Legacy Modernization (Month 2+)

What Thomas Does

Thomas deploys targeted AI refactoring to modernize legacy systems without stopping new feature delivery.

Strategy: parallel modernization:

  • New features continue on the current architecture. Nobody waits for the refactor to finish.
  • Legacy modules get AI-assisted refactoring in parallel. Each module gets its own ticket, plan, and validation cycle.

What he uses:

  • Tickets to track each modernization task with clear acceptance criteria
  • Plans to define the refactoring approach with explicit constraints (e.g., "preserve all public function signatures")
  • TDD to ensure existing behavior is preserved through test coverage
  • Review queue to verify the refactoring before merge
  • Knowledge base to document architectural decisions

What he measures quarterly:

  • Lines of legacy code reduced
  • Test coverage increase on modernized modules
  • Bug rate change in refactored areas
  • Developer time saved on maintenance tasks

What he does not do:

  • Let AI rewrite entire systems in one pass
  • Skip code review for simple changes
  • Merge without test coverage

He reports to the board: "Legacy code reduced 15% this quarter. Test coverage on modernized modules went from 40% to 78%. Bug rate dropped 12% in refactored areas."

What He Sees

  • Parallel modernization running alongside new features
  • Measurable reduction in legacy code
  • Test coverage increasing
  • Bug rate decreasing in refactored areas

Why This Works for Thomas

Legacy modernization is a multi-quarter effort. WayOfTeams gives him the tracking, planning, and quality gates to execute it without disrupting new feature delivery.

Phase 7: Build vs Buy Decisions (Ongoing)

What Thomas Does

Thomas evaluates continuously. What WayOfTeams gives him that he would otherwise build:

Component Build Cost WayOfTeams
Multi-tenant architecture 6+ months engineering Included
Agent orchestration with HITL 3+ months engineering Included
MCP server with 125 tools 4+ months engineering Included
Audit trail with f-rr-d 2+ months engineering Included
Total $500K+ in engineering time Subscription

He monitors the vendor roadmap. He evaluates lock-in risk quarterly. He ensures data portability through Git-backed f-rr-d. He keeps an exit strategy documented.

What He Sees

  • Build vs buy comparison with real cost estimates
  • Vendor roadmap reviewed quarterly
  • Exit strategy documented
  • Data portability confirmed

Why This Works for Thomas

He does not make emotional decisions. He makes financial ones. WayOfTeams saves him $500K+ in engineering time and gives him a platform that scales with his organization.

Feature Adoption Order

Based on Thomas's profile, here is what he uses and when:

Priority Feature Why Thomas Cares
1 Tenant isolation and RBAC Security posture must survive CISO review
2 Cost monitoring and quotas Prevent AI budget blowout as usage scales
3 Audit trail (mcp_audit) Regulatory compliance and board reporting
4 HITL layers Human oversight for high-risk AI decisions
5 Task-based model routing Optimize cost per task across local and cloud
6 Knowledge and rules Enforce architectural standards company-wide
7 Review queue Quality gate before AI code reaches production
8 Pilot metrics Prove ROI to board before company-wide rollout
9 f-rr-d change tracking Data portability and vendor lock-in prevention
10 Version management Track system changes with rollback capability

What Makes WayOfTeams Different for Thomas

Problem Thomas Has WayOfTeams Solution
"I need to prove ROI before approving spend" Pilot metrics, cost per developer, throughput measurements
"I cannot let AI expose proprietary code" JWT tenant isolation, secret-masking proxy, RBAC
"AI spend will blow out my budget" Task-based model routing, quotas, local inference option
"Regulators will ask what AI did" mcp_audit, Agent Ops, f-rr-d, complete audit trail
"I need to modernize legacy without stopping features" Parallel modernization with tickets, plans, TDD, review queue
"Vendor lock-in is a strategic risk" Git-backed f-rr-d, data portability, exit strategy
"I need to bridge engineering and the board" Dashboard metrics, cost reports, throughput measurements
"Security and speed are in tension" HITL layers balance automation with oversight

The Core Loop

For Thomas, WayOfTeams enforces one strategic discipline:

Evaluate -> Pilot -> Govern -> Measure -> Optimize -> Report -> Evaluate
    ^                                                             |
    +-------------------------------------------------------------+

Every iteration strengthens the business case:

  • Evaluate determines if the platform meets security and cost bars
  • Pilot proves value with a controlled group before scaling
  • Govern locks down access, secrets, and compliance
  • Measure tracks throughput, quality, cost, and satisfaction
  • Optimize adjusts model routing, quotas, and local inference mix
  • Report presents ROI to the board and cost to the CFO
  • Evaluate revisits vendor and platform decisions quarterly

The loop runs through a platform that handles tenancy, governance, compliance, and cost control so Thomas can focus on the strategic question: "Does this make us stronger?"

That is the system Thomas would approve for his organization.

← Back to all personas