PowerUp Coaching — Living Knowledge Base

Part 5c: An Ambient Folder Matures: Layers, Roles, and Contracts

6 min read

Your ambient folder now works. You can write essays. You can validate them. The harness knows your standards and enforces them.

But you’re a solo practitioner with one type of output. What happens when you scale?

  • You want multiple people contributing (not just you)
  • You want multiple types of work happening simultaneously (essays, concepts, research summaries)
  • You want some operations to depend on others (an essay can’t be published until it’s been reviewed and approved)
  • You want different roles to have different capabilities (your editor can review but not publish; your researcher can add to the knowledge base but not publish essays)

This is where a mature ambient folder adds layers: roles, contracts, and orchestration.

Adding layers: the matured structure

Your original folder had this shape:

source/ → drafts/ → output/ → [publish]

As you mature, you add layers that handle complexity:

source/
  ├── raw inputs

working/ (new)
  ├── assigned tasks
  ├── in-progress work
  └── peer-reviewed drafts

output/
  ├── ready to publish
  └── published

archive/ (new)
  ├── old pieces
  └── versions/history

And you add workflow definitions:

workflows/
  ├── essay.workflow.yml     # How essays move through the system
  ├── concept.workflow.yml   # How concepts move through the system
  └── review.workflow.yml    # Review and approval process

And you add role definitions:

roles/
  ├── author.yml             # Can create and edit work
  ├── reviewer.yml           # Can comment and approve
  ├── editor.yml             # Can make final edits
  └── publisher.yml          # Can publish to live

This structure encodes the complexity without creating chaos.

Contracts: defining what happens at each stage

A contract specifies what must be true before work can move from one stage to the next.

Create workflows/essay.workflow.yml:

workflow: essay
stages:
  - name: draft
    description: "Initial generation"
    who_can_enter: [author, ai]
    contract:
      - Must have valid frontmatter
      - Must have title (5-120 chars)
      - Must have description (10-200 chars)
      - Must be 1000+ words
    can_move_to: [review]
 
  - name: review
    description: "Peer review and feedback"
    who_can_enter: [reviewer]
    contract:
      - Must have review comments
      - Reviewer must approve or request changes
    can_move_to: [revision, published]
 
  - name: revision
    description: "Address review feedback"
    who_can_enter: [author, ai]
    contract:
      - Must address all review comments
      - Must update modified date
      - Can re-submit for review or move to published
    can_move_to: [review, published]
 
  - name: published
    description: "Live on the site"
    who_can_enter: [publisher]
    contract:
      - Must have passed review
      - Must have correct metadata
      - Must be syntactically correct
      - Draft field must be false

This workflow defines:

  • Stages: the states work moves through
  • Who can enter: which roles can perform actions at each stage
  • Contracts: what must be true to enter the stage
  • Transitions: where work can go next

This encodes your actual process in machine-readable form.

Roles: defining what each actor can do

Create roles/author.yml:

role: author
permissions:
  - create:draft
  - edit:draft
  - edit:revision
  - submit:review
  - view:feedback
 
restrictions:
  - cannot:publish
  - cannot:edit:published
  - cannot:delete:published

Create roles/reviewer.yml:

role: reviewer
permissions:
  - view:draft
  - view:revision
  - comment:draft
  - comment:revision
  - approve:review
  - request_changes:review
  - view:feedback
 
restrictions:
  - cannot:edit:content
  - cannot:publish

Create roles/publisher.yml:

role: publisher
permissions:
  - view:published
  - publish:prepared
  - unpublish:published
  - view:metadata
 
restrictions:
  - cannot:edit:content
  - cannot:delete:published

Roles are defined by what they can and cannot do. This is more granular than just “admin” or “viewer.” Different people have different capabilities, and that’s encoded explicitly.

Multi-agent operations: composing roles

Here’s where it gets interesting. You can now define operations that require multiple agents in sequence.

Create workflows/publish-essay.orchestration.yml:

operation: publish_essay
triggers:
  - when: essay reaches "published" stage
  - and: all review contracts are satisfied
  - and: all quality checks pass
 
steps:
  - name: "Final technical validation"
    actor: system
    action: validate_all_schemas
    on_failure: reject
    
  - name: "Final editorial review"
    actor: publisher
    action: review_metadata_and_tone
    approval_required: true
    on_failure: return_to_author
    
  - name: "Generate final HTML"
    actor: ai_formatter
    action: render_essay_to_html
    use_context: [template, styles, previous_publications]
    
  - name: "Publish to site"
    actor: publisher
    action: deploy_to_live
    confirmation_required: true
    
  - name: "Update knowledge base"
    actor: ai_linker
    action: create_backlinks_and_metadata
    dependencies: [essay is live]
    
  - name: "Archive version"
    actor: system
    action: commit_to_version_control
    message: "Published: [title]"

This orchestration defines a publishing workflow:

  1. The system validates everything
  2. A human publisher does final review
  3. An AI formatter generates the output
  4. A human publisher confirms and deploys
  5. An AI agent creates knowledge base links
  6. The system archives the version

Each step has a clear actor, clear action, clear dependencies, and clear failure modes. If any step fails, the workflow stops and reports what happened.

How this scales the ambient folder

With these additions, your folder can now:

Handle complexity — multiple workflows, multiple types of work, multiple people

Distribute responsibility — different roles have different capabilities and restrictions

Automate coordination — workflows handle the sequencing; humans just do their part

Trace accountability — every operation is logged with who did it and when

Scale without chaos — new people can join and immediately understand what they can do

You’re no longer managing a folder with a simple input-output flow. You’re managing a system that coordinates multiple people, multiple capabilities, and multiple types of work.

What changes about ambient AI at this scale

When your folder is mature, what does “ambient” mean?

At the simple level, it meant the AI was invisible because it was automatic. You didn’t have to explicitly call it.

At the mature level, it means the AI is invisible because it’s woven into your actual operations. The author doesn’t think about the AI. They draft an essay and submit it. The AI happens to be involved in generating it, but that’s infrastructure.

The reviewer doesn’t think about the AI. They review an essay and approve it. An AI might later be involved in generating the formatted version or creating knowledge base links, but again, that’s transparent.

The system handles the orchestration. People just do their work.

This is where “ambient” stops being a metaphor and starts being the actual shape of the operation.

Building toward layer cascades

The final piece on scaling explores what happens when these layers cascade: when folders connect to other folders, when operations inherit capability from shared infrastructure, and when ambition expands beyond a single person’s practice.

But before that, we look at one more thing: what happens when this infrastructure becomes so natural that it disappears entirely from consciousness.

Graph View