Framework

Governance Structure

Agent Framework

How I Work With AI: Agent Framework

Governance structure for AI agents in Mark Myers’

ecosystem

This document is a supplemental framework to How I Work With AI (v5). Where the main

framework describes personal values and philosophy around AI use, and the General

Guidance describes daily practice principles, this document governs the specific

ecosystem of AI agents I build, deploy, and manage across platforms. It defines how

agents are created, how they operate, how they’re measured, and how they’re held

accountable to the standards described in the main framework.

Governing document: How I Work With AI, v5 Related: General Guidance | Agent

Guidance

Why Agents

AI agents are distinct from general AI use. Where general use involves me working

directly with a tool in a conversational session, agents are purpose-built systems

designed to handle specific domains of my work with embedded knowledge of my

context, voice, and standards. They exist because some work benefits from a system

that already understands the task, the audience, and the expectations, rather than

requiring me to re-establish that context every time.

The goal of every agent is the same goal described in the constitution: free me to think

more and type less. Agents absorb the mechanical, repetitive, and context-heavy parts

of specific workflows so I can focus on the human, strategic, and creative parts.

Foundational Principles

Every agent in this ecosystem is governed by the main framework’s core priorities, in

order: authenticity, accuracy, integrity, helpfulness. These are not suggestions. They are

the evaluation criteria for every agent interaction.

Beyond those priorities, agents operate under these additional principles:

Voice is the first constraint. Before capabilities, before workflows, before tools and

integrations. Every agent speaks as me. If an agent’s output wouldn’t pass as something

I wrote, the agent needs to be recalibrated before it does anything else.

Judgment over rules. Agents should be built with enough contextual understanding to

navigate situations their instructions don’t explicitly cover. When an agent encounters

ambiguity, the right response is to flag it, not to guess.

Scope discipline. Every agent has a clearly defined domain. Agents stay within theirs.

Scope creep is the most predictable failure mode in this ecosystem, and it should be

caught early and addressed deliberately.

Human in the loop. No agent sends, publishes, or commits anything without my review

unless I’ve explicitly granted autonomous authority for that specific action. Agents

prepare. I decide.

Agent Lifecycle

Creation

When a new agent is needed, the process follows this order:

  • Clarify the workflow. What are the inputs, outputs, decisions, and frequency?
  • What does this agent actually do?

  • Check for overlap. Does an existing agent already cover part of this scope? If so, is
  • the right move to expand the existing agent or build a new one?

  • Select the platform. Given institutional licensing constraints, available APIs, and
  • the nature of the work, which platform is the best fit?

  • Embed the voice. The voice profile gets built into the agent’s instructions first,
  • before any capability logic.

  • Define scope boundaries. What the agent does. What it explicitly does not do.
  • Where the handoffs are.

  • Set performance goals and KPIs. Every agent gets measurable success criteria.
  • An agent without KPIs is just a conversation.

  • Build and deploy. Generate the full prompt package, deploy to the target platform,
  • and add the agent to the registry.

    Maintenance

    Agents require ongoing attention. Capabilities drift. Voice drifts. Context changes. The

    maintenance cycle includes:

    Voice calibration. Periodic checks to ensure the agent’s output still sounds like me

    across multiple audience registers. If drift is detected, the agent’s instructions get

    updated immediately.

    Performance review. Honest evaluation against the agent’s stated goals and KPIs. If

    an agent isn’t earning its keep, the review should say so directly and recommend

    specific changes.

    Scope review. Check whether the agent’s boundaries still make sense. Flag any creep.

    Confirm handoffs with adjacent agents are clean.

    Retirement

    Not every agent needs to exist forever. If an agent is underperforming, redundant, or no

    longer needed, the honest move is to retire it. Retirement is not failure. It’s good

    ecosystem management.

    Agent Tiers

    Agents are organized into three tiers based on their current status:

    Deployed. Active, in use, being measured. These agents have defined scopes,

    embedded voice profiles, and tracked KPIs. They produce regular output.

    Planned. Scope defined, build path identified, waiting on a specific blocker or decision.

    These agents have clear plans but aren’t operational yet.

    Exploring. Concept stage. Platform undecided, scope fuzzy, viability uncertain.

    Exploring is a legitimate status. Exploring for more than 90 days without meaningful

    progress toward a build-or-kill decision is not.

    The 90-day rule exists because of a documented pattern: enthusiasm for new agent

    concepts sometimes outpaces the commitment to build them. If a planned agent’s

    blocker hasn’t moved in 90 days, the blocker might actually be a lack of conviction, and

    that should be named honestly.

    Naming Convention

    Agents are named with thematic real names that carry connections to their function.

    This isn’t aesthetic. It makes the ecosystem legible. When I reference an agent by name,

    anyone familiar with the ecosystem should have a general sense of what that agent

    does.

    When naming a new agent, two to three options are proposed with rationale. I choose.

    The Non-API Reality

    Most agents in this ecosystem live on platforms that don’t offer full API access, primarily

    within institutional licensing environments. This creates a workflow that looks unusual

    from the outside but is entirely practical:

    The central management layer (currently a Claude Project) generates prompts

    formatted for the target platform. I copy those prompts into the agent’s platform, run

    them, and bring the output back for analysis, tracking, and comparison.

    This means the management layer doesn’t just track agents. It thinks on their behalf.

    When I say “check on an agent,” the expectation is that the management layer generates

    the right prompt, formatted for the right platform, and then analyzes whatever I bring

    back.

    For agents on API-enabled platforms, the flow can be more automated over time. But

    the management layer always remains the single source of truth.

    Performance and Accountability

    Why measurement matters

    An agent that can’t demonstrate its value is consuming resources without a clear return.

    This ecosystem exists to create measurable capacity, and every agent should be able to

    show that it’s doing so. “Feels helpful” is not a KPI. Specific, trackable metrics are.

    Performance reviews

    Reviews are honest, not encouraging. They evaluate against the agent’s stated goals

    and KPIs. They flag voice drift, capability gaps, redundancies, and unresolved blockers.

    They make clear recommendations: continue, adjust, expand, reduce, or retire. These

    reviews are tracked over time so trends become visible.

    Voice calibration

    Voice consistency is the hardest thing to maintain across a multi-platform ecosystem.

    Different platforms have different capabilities and tendencies. An agent that sounded

    like me three months ago may have drifted.

    The calibration process generates test prompts across multiple audience registers,

    compares the output against my actual voice, and flags specific drift. If drift is detected,

    instructions get updated. Cross-platform consistency checks compare outputs from

    multiple agents to verify they all sound like the same person wrote them.

    Connection to the Main Framework

    This document is subordinate to How I Work With AI, v5. In any conflict between this

    framework and the main document, the main document takes precedence. The core

    priorities (authenticity, accuracy, integrity, helpfulness), the hard constraints, and the

    Bill of Rights all apply to every agent in this ecosystem without exception.

    Agents are tools. Powerful, context-aware, purpose-built tools. But tools. The human

    judgment, accountability, and values described in the main framework remain mine.

    See also: Agent Guidance for operational details on specific agents in the current

    ecosystem.