How Marcus, The Enterprise AI Systems Architect, Uses WayOfTeams

A step-by-step walkthrough of how a senior systems architect designs and operates scaled multi-agent enterprise infrastructure on WayOfTeams — with governance, compliance, and production-grade safety at every layer.

Who Marcus Is

Marcus has moved beyond building individual tools or personal workflows. As a senior systems architect and strategist, he designs and deploys scaled, multi-agent enterprise infrastructure and production-grade local/hybrid networks. Where Alex experiments with scripts and individual harnesses, Marcus builds the standard operating systems, governance frameworks, and autonomous pipelines that entire organizations run on.

He deploys resilient, multi-tenant hybrid environments combining cloud clusters with local enterprise hardware — high-bandwidth multi-GPU rigs, dedicated model servers. He implements stateful multi-agent consensus networks, robust authorization layers, dynamic RAG with vector and graph databases, and custom context recovery pipelines.

He is deeply focused on system reliability, zero-trust data access, hardware resource optimization, and strict regulatory models like EU AI Act compliance or MiCA frameworks for automated financial agents.

He thinks in system diagrams, SLAs, concurrency limits, hardware bandwidth, and business unit integration. He focuses on total cost of ownership, scale, and long-term viability over short-term tech hypes.

Phase 1: Setting Up the Organization Hierarchy (Day 1)

What Marcus Does

Marcus signs up with GitHub. He skips the onboarding questions — he is not building a personal project. He goes straight to Admin, Company Settings. He creates the structure that matches his org chart:

Company: Acme AI Solutions
  Organization: North America
    Department: Engineering
      Team: Platform
      Team: AI Research
    Department: Operations
      Team: DevOps
  Organization: Europe
    Department: Engineering
      Team: Platform
    Department: Compliance
      Team: Regulatory
  Organization: APAC
    Department: Engineering
      Team: Localized AI

He invites team leads by email. Each person gets the right role:

Role Access Who Gets It
Superadmin Full system access Himself and ops lead
Admin Company settings, team management Department heads
Lead Review queue, ticket approval, kanban Team leads
Developer Tickets, kanban, AI chat, standups Individual contributors
Viewer Read-only dashboard Stakeholders, non-technical PMs

He configures company settings: project prefix, default ticket namespace. He sets up entitlements: which teams get which features. Some teams do not need hosted workspaces. Others need GPU access.

What He Sees

  • Org chart hierarchy matching his business structure
  • Role-based access at every level
  • Entitlements controlling feature access per team
  • Each level can have its own settings and members

Why This Works for Marcus

He has built org hierarchies in enterprise tools before. WayOfTeams has the right structure: Company -> Organization -> Department -> Team -> Developer. Each level maps to a business unit. He does not need to hack multi-tenancy onto a single-tenant tool.

Phase 2: Locking Down Permissions (Day 1–2)

What Marcus Does

Marcus does not trust default permissions. He locks everything down before anyone logs in.

Board-level permissions:

Each kanban board has roles: owner, admin, member, viewer. Private boards (scope: private) are invisible to everyone except the owner. Not just hidden. Truly invisible. He tests this by having a pilot developer try to access a board they do not own. Access denied.

He creates company-wide boards visible to all, and private boards per department. Engineering gets their own board. Operations gets theirs. Compliance gets theirs. Each board has the right people with the right access.

MCP-level permissions:

Every MCP call carries a JWT with company_id derived from the authenticated developer. Tenant isolation is enforced at the database layer. He verifies this by testing:

Can Developer A from Company X read Company Y tickets?

No. The isolation holds at every level. He tries from the API, from the MCP, from the dashboard. Every path is blocked.

Review queue:

He configures the review queue so all code changes require lead approval before merge. The queue shows PR status, ticket linkage, and approval history. Leads get notifications when reviews are pending. Nothing ships without a human signature.

Coordinator role:

He designates a system agent as the coordinator for each project. The coordinator controls FREEZE/GO for merges and deploys. The coordinator cannot write code (WOTEAMS-404) — it is a track/verify/ deploy role only. This prevents agent escalation.

What He Sees

  • Board permissions enforced at UI and MCP level
  • Tenant isolation verified at database layer
  • Review queue with approval workflow
  • Coordinator role with hard write boundary

Why This Works for Marcus

He has designed zero-trust architectures before. WayOfTeams enforces tenant isolation at the JWT level, board isolation at the role level, and code safety at the coordinator level. The three HITL layers give him fine-grained control over what agents do autonomously vs what requires human approval.

Phase 3: Configuring HITL Layers per Agent (Day 2–3)

What Marcus Does

Marcus sets the Human-in-the-Layer for each agent. This is critical for compliance — the EU AI Act requires human oversight for high-risk AI decisions.

Layer 1 (Auto): ticket_manager — ticket creation is safe, no human approval needed for each one. backlog_groomer — prioritization is low-risk. These run without interruption.

Layer 2 (Notify): debugger — runs and logs everything, but a human is notified after execution. auto_ticket_creator — creates tickets and notifies the lead. These run, but humans are informed.

Layer 3 (Escalate): github — merges require human approval before they happen. The agent pauses and waits. This is the highest risk category. Nothing ships without a human saying yes.

He documents the HITL configuration for his CISO:

"Every agent action is logged. Low-risk actions run automatically. Medium-risk actions notify a human after execution. High-risk actions pause and wait for human approval before execution. No agent can write code. The coordinator role is track/verify/deploy only."

What He Sees

  • HITL layer assigned to every agent
  • Escalation path documented for auditors
  • No agent can bypass human oversight for high-risk actions
  • Coordinator cannot write code — hard boundary

Why This Works for Marcus

He has built multi-agent systems where agents ran unchecked. One agent rewrote a production database schema without approval. WayOfTeams prevents this: Layer 3 Escalate means the agent stops and waits. The human decides.

Phase 4: Deploying Multi-Agent Orchestration (Week 1)

What Marcus Does

Marcus deploys multiple Jido agents across his teams:

Agent Team Purpose HITL Layer
ai_assistant Platform Multi-provider ReAct, ~60 tools Layer 1
ticket_manager All Ticket lifecycle management Layer 1
github Platform Branch, PR, release, review Layer 3
debugger Platform Log analysis, state inspection Layer 2
research AI Research Codebase research and synthesis Layer 1
tdd Platform Red-green-refactor test cycles Layer 1
backlog_groomer Operations Backlog prioritization Layer 2
auto_ticket_creator All Monitor sources, create tickets Layer 2

Each agent runs through the Orchestrator — the central routing layer. The Orchestrator checks the HITL layer before executing any action.

The coordinator role controls FREEZE/GO for merges and deploys:

Before any merge:
  Coordinator issues FREEZE
  All agents acknowledge and stop git operations
  Coordinator verifies: working tree clean, branches merged,
    stashes reconciled, mix compile + mix test pass
  Coordinator signals GO
  Merge proceeds

Work visibility shows who is touching what. Every agent declares its work via update_my_work. File conflicts are detected via conflicts before any edit. If two agents need the same file, the coordinator assigns ownership.

What He Sees

  • 8+ agents deployed across teams with clear responsibilities
  • HITL layers enforced per agent
  • FREEZE/GO protocol for merges
  • Work visibility preventing file conflicts
  • Coordinator cannot write code

Why This Works for Marcus

He has built multi-agent systems where agents silently conflicted on the same files, or where a runaway agent corrupted production data. WayOfTeams solves this with the coordinator role, work visibility, conflict detection, and three-layer HITL. He scales from 2 agents to 20 without losing control.

Phase 5: Monitoring via Agent Hub and Audit (Week 1–2)

What Marcus Does

Marcus opens the Agent Hub (Collaboration page). He sees:

AGENT STATUS:

ai_assistant    | Online  | Working on: WOTEAMS-142 | Layer 1
ticket_manager  | Online  | Idle                     | Layer 1
github          | Busy    | PR review pending        | Layer 3
debugger        | Online  | Last run: 2 min ago      | Layer 2
research        | Offline | Maintenance              | Layer 1
tdd             | Online  | Running tests            | Layer 1

He runs mcp_audit through the MCP:

"Show me the last 50 MCP write operations, filtered by outcome"

He sees every create, update, and push — who did it, when, what succeeded, what failed. The audit store persists structured failure metadata so production errors surface in the Superadmin dashboard.

He checks the Superadmin, Agent Ops page:

  • Agent invocation logs: 1,247 invocations this month
  • Failure rate: 2.3% (mostly timeout on external API calls)
  • HITL compliance: 98% of Layer 3 actions had human approval within 4 hours

What He Sees

  • Real-time agent status and work in progress
  • Audit trail for every tool call
  • Failure rates and HITL compliance metrics
  • Invocation counts and trends

Why This Works for Marcus

He needs to show his CISO and auditors that every AI action is traceable. The Agent Hub gives him real-time visibility. The mcp_audit gives him historical data. Together they form a complete audit trail.

Phase 6: Setting Up Cloud Sync Across Regions (Week 2–3)

What Marcus Does

Marcus configures hub/edge topology for his hybrid infrastructure:

                    ┌─────────────────┐
                    │   Azure Hub     │
                    │  (Primary)      │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────┴───────┐ ┌───┴────────┐ ┌──┴──────────┐
     │ Edge: NA Office│ │ Edge: EU   │ │ Edge: APAC  │
     │ (DevOps)       │ │ (Compliance│ │ (Localized) │
     └────────────────┘ └────────────┘ └─────────────┘
  • Oplog-based change tracking with LWW conflict resolution
  • Real-time SSE streaming between instances
  • Tenant-scoped: each company's data syncs independently
  • Sensitive data pinned to specific regions via deployment config

What gets synced: tickets, plans, standups, docs, knowledge, rules, agent messages, shared contexts, agent work status, coordinator role, agent health.

What stays local: LM Studio model files and inference state, GPU allocations, sensitive data pinned to specific regions.

He tests: creates a ticket on the hub, sees it appear on the edge within seconds. Creates a ticket on the edge, sees it on the hub. Sync works bidirectionally.

What He Sees

  • Hub/edge topology with clear data flow
  • Bidirectional sync working in real-time
  • Tenant-scoped replication
  • Sensitive data pinned to regions

Why This Works for Marcus

He has built sync systems from scratch. WayOfTeams gives him hub/edge topology, oplog-based change tracking, and conflict resolution out of the box. He can run Azure as the hub and deploy edge instances in client offices — all staying in sync.

Phase 7: Building White-Label Platforms (Month 2+)

What Marcus Does

Marcus customizes WayOfTeams for industry verticals:

Construction management:

  • Ticket namespace: CONSTRUCTION-XXX
  • Board template: Site Survey -> Permits -> Construction -> Inspection -> Closeout
  • Knowledge base: OSHA regulations, safety requirements
  • Rules: construction coding standards

Clinical health:

  • Ticket namespace: HEALTH-XXX
  • Board template: Intake -> Assessment -> Treatment -> Documentation -> Discharge
  • Knowledge base: HIPAA requirements
  • Rules: clinical data handling standards

Financial services:

  • Ticket namespace: FINANCE-XXX
  • Board template: Compliance Review -> Risk Assessment -> Approval -> Implementation -> Audit
  • Knowledge base: MiCA frameworks
  • Rules: financial data compliance standards

Each vertical gets its own company settings, its own entitlements, its own board templates. The underlying platform is the same. The customization is in the configuration, not the code.

What He Sees

  • Industry-specific board templates
  • Vertical-specific knowledge and rules
  • Ticket namespaces per industry
  • Same platform, different configurations

Why This Works for Marcus

He evaluated building this from scratch — 18 months and $2M+ in engineering costs. WayOfTeams gives him the foundation: multi-tenancy, governance, agent orchestration, compliance. He customizes the vertical layer and ships in months, not years.

Feature Adoption Order

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

Priority Feature Why Marcus Cares
1 Company Hierarchy Org chart matching with multi-tenant isolation
2 Board Permissions Role-based access per board
3 HITL Layers Auto/Notify/Escalate per agent
4 Coordinator Role FREEZE/GO protocol, cannot write code
5 Agent Hub Real-time agent status and work visibility
6 mcp_audit Every tool call logged with outcome
7 Cloud Sync Hub/edge topology across regions
8 Rules & Knowledge Enforce standards per vertical
9 Review Queue Quality gate before code reaches production
10 Version Management Track changes with rollback
11 Entitlements Tiered feature access per client
12 Agent Ops Invocation logs and HITL compliance

What Makes WayOfTeams Different for Marcus

Problem Marcus Has WayOfTeams Solution
"I need multi-tenant isolation I can prove" JWT isolation at DB level, board permissions, private scopes
"Agents conflict on shared files" Work visibility registry, coordinator role, conflict detection
"I cannot show auditors what AI did" mcp_audit, Agent Ops, f-rr-d, complete action logs
"I need hybrid cloud + local" Cloud Sync hub/edge topology, oplog-based sync
"I need to white-label for clients" Multi-tenant architecture, company settings, entitlements
"I need HITL for compliance" Three-layer HITL per agent, auditable escalation logs
"I need governance at scale" Company -> Org -> Dept -> Team hierarchy, RBAC, review queue
"I need observability" OTel built in, mcp_audit, Agent Ops, Oban monitoring

The Core Loop

For Marcus, WayOfTeams enforces one operational discipline:

Govern -> Deploy -> Orchestrate -> Monitor -> Audit -> Optimize -> Govern
  ^                                                                |
  +----------------------------------------------------------------+

Every iteration strengthens the system:

  • Govern sets the rules, roles, and compliance boundaries
  • Deploy pushes infrastructure across hybrid environments
  • Orchestrate runs multi-agent workflows with HITL control
  • Monitor tracks health, performance, and cost in real-time
  • Audit proves compliance to regulators and stakeholders
  • Optimize reduces TCO through model routing and resource tuning
  • Govern closes the loop with updated policies and entitlements

The loop runs through a platform that handles tenancy, governance, compliance, and multi-agent coordination — so Marcus can focus on building the industry-specific systems his clients actually need.

That is the system Marcus would bet his infrastructure on.

← Back to all personas