Frames In Practice

Your context, guiding AI.

A Frame is versioned, shareable context. It encapsulates normative knowledge that aligns AI with how you work. Frames take minutes to create and give lasting value.

Frames guide the work. Write one, and it keeps guiding it.

00

Your context leaks away.

The models are capable. What is missing is a portable container for the rules, terminology, goals, and norms that turn generic AI into your organization’s work, so the context stays with the organization that produced it.

Context dissipation

No container for organizational rules, terminology, and norms. Every session re-sets the stage from scratch.

Brand and policy drift

The same question gets a different answer depending on who asked, in which chat, on which day.

Value leakage

The context that produced a good result stays in one person's prompt history. It cannot be reviewed, reused, or handed on.

No record of what governed it

When guidance lives in prompts, nobody can say afterwards which rules shaped a decision, or who owned them.

“In consuming intelligence, you are creating intelligence. And what you create should belong to you.”

A Frame is that container: written once, versioned, owned, and activated where the work happens.

01

Frame your context.

01

Capture

What people always have to be told before they can start.

02

Write

A Markdown file containing norms, definitions, and other context. One page is plent

03

Use

Frames in your agent or toggle it on in Collab. From then on it shapes every answer.

04

Share

Managed context to stay aligned. In Collab the owner, visibility, and history travel with it.

05

Own

Maintain and improve your Frames and AI becomes an effective member of your work group.

WHY DO IT?

Every session starts warm

Open a chat and the stage is already set. The first useful answer arrives first.

Context becomes an asset

Written once, versioned, and owned. It appreciates with every revision instead of evaporating.

Consistency compounds

The same terminology and rules for everyone, so quality holds as the team and the work grow.

Answers you can trust

Collab shows exactly which Frames shaped an answer, so you can trust it and improve it.

02

A Skill teaches an assistant how to perform a task. A Frame tells it whose work this is and what governs it.

Skill

Frame

What it answers

How do I do this?

Who are we, and what are the rules?

How it activates

Invoked for a task, then done
Added to a session and stays on as context
How long it lasts
The length of the task
Until someone changes or retires it
Whether it composes
Usually one at a time

Several can be layered together

Who owns it
Whoever wrote the procedure
A named maintainer, on the record
Crosses org boundaries
Portable; it carries no allegiance

Deliberately, with a review and deliberation

vs. a system prompt

A prompt lasts a session and is unowned. Nobody can review or version it.

vs. a wiki page

A wiki page holds the same knowledge, but someone has to find it and read it. A Frame you just switch on.

03

Frames are focused and layered.

Brand Voice

How we sound, and the words we never use.

Methodology

The way this team does the work, in order.

Project

Goals, terminology, and constraints for one effort.

Partner

What an outside collaborator needs to know, and no more.

Compliance

The rules that are not negotiable, stated as rules.

Scope, widest to narrowest

Company

Vocabulary · values · brand voice · norms

Team

Style · conventions · audience

Project

Goals · terminology · constraints

Personal

Your own working preferences

Where to start

Start where the pain is sharpest and the review loop is shortest, usually team or project.

Don’t design the whole hierarchy before anyone has used one Frame.

04

It's a Markdown file.

editorial-style-guide.md

type: frame [0.2]
name: Editorial Style Guide
description: How we write for customers, and what we never say.
visibility: shared
version: 0.3.0
scope: department
maintainer: dana.k
inherits: company-frame


# Editorial Style Guide

## Terminology

– We say “release”, never “drop”.
– Customers are “customers”, not “users”.

## Rules

– Headlines are Title Case. No exceptions.
– Never publish a claim without a linked source.

## Style

– Second person. Short sentences.
– No hype adjectives.

Frontmatter

Four fields are required. The rest matter once the Frame is shared and revised by other people.

Body

Terminology, goals, rules, style, norms. No fixed taxonomy required. Use the headings your team already thinks in.

Every field, defined →
Frame Spec v0.2 is reproduced in full at the bottom of this page.

Write rules as decidable statements

Headlines are Title Case” can be checked. “Be excellent” cannot. If you can’t tell whether an output broke the rule, it isn’t a rule.

Keep it short

It loads as context, where tokens are at a premium. Too long to read quickly is too long to be useful.

05-07

The models are capable. What is missing is a portable container for the rules, terminology, goals, and norms that turn generic AI into your organization’s work, so the context stays with the organization that produced it.

Fastest first draft, most editing

Consolidate the context and rules.

Connect your AI to Drive, Slack, Gmail, …, and have it create a first draft.

Extract

Point it at existing material and ask for a Frame draft, not a summary.

Harvest

After a work session, ask what you had to tell it that a Frame should have carried.

Critique

Hand it the draft and the spec; ask what is bloated or unenforceable.

Share

Put the draft in front of the people who know. Their corrections are the feedback the agent cannot give you.

The part that actually matters

Agents draft. You edit. Nothing about that is optional.

Agents are verbose. Expect to cut the draft by half.

Every rule must be decidable. Strike the aspirational lines.

Ownership cannot be delegated. The maintainer is a person who read and is accountable for every line.

Agents copy what they read. If a password or API key was in the source material, delete it from the draft.

Point the agent at this page, where Frame Spec v0.2 is reproduced in full, and ask it to conform to the spec rather than to your description of it.

Owned and shared with a click

Create, activate, and share in one place.

Permissions, ownership, and history come with it. You don’t add them later.

01 · Create

In the Frames tab

Name, description, visibility, owner. Four fields and you have a Frame.

02 · Organize

Tags and Frame Groups

Bundle related Frames so the right set comes in together.

03 · Activate

Toggle on and layer

Turn one on in chat, or several, and see what's active while you work.

04 · Share

Access lists and owners

Set who can read, who can edit, and who answers for it.

05 · Review

Change history

Every edit is a version. You can see what changed and who changed it.

Frames

Step 03 · activation
Company

OpenTeams

Rules · norms · language

Editorial Style

Layered over Company

Project

Q3 Launch

Expires 30 Sep

Partner

Northwind

Read-only · external access

Collab shows which Frames are active while you work with your agent.

Any text editor will do

A file is enough.

Write it in whatever you already use. This is the path when the Frame is drafted outside Collab or kept alongside other files that are versioned together.

frames/api-conventions.md



type: frame [0.2]
name: API Conventions
description: How we name and version endpoints.
visibility: internal
maintainer: sam.r



## Rules

– Paths are plural nouns: /invoices, not /invoice.
– Every breaking change ships behind a version prefix.
– Errors return a machine code and a human message.

Checklist

Four required fields present

Every rule decidable

A named maintainer

No credentials, no personal data

Reads in under two minutes

Import into Collab

Bring the file in and Collab adds what a shared Frame needs on arrival: visibility, ACLs, an owner, and version history.

One warning

Decide where the source of truth lives. Editing in both places and re-importing overwrites.

Frames need no infrastructure to share. Email, chat, a shared folder, or a repository all work.

08

Same prompt. Different answer.

One Frame makes a big difference.

“Compile my to-do list.”

Same account, same day, same model. The only difference is whether the Client Delivery Frame was active. →

client-delivery.md

Without the Frame

You

Compile my to-do list.

8 items found in your inbox, slack, and calendar. Ordered by severity.

Return the security questionnaire to IT

· internal

Approve the Q3 headcount plan

· internal

Draft the launch retro document

· internal

Prep for the Northwind renewal call

· Client

Review the OKR spreadsheet before Friday

· internal

Submit two overdue expense reports

· internal

Comment on the design review thread

· internal

Reply to Priya’s question about the migration window

· Client

Priya’s email asks when the migration window can move. She assumed the reader is aware of project timelines. That connection is written in the project plan, which the agent never thought to open, so the email scores Low and lands at the bottom of the list.

You

Compile my to-do list.

Project plan reviewed. Client commitments first, per Client Delivery.

Unblock Northwind’s data migration before Thursday’s cutover.

Prep for the Northwind renewal call on Friday

Send Aster the revised delivery date you promised in writing

Return the security questionnaire to IT

Approve the Q3 headcount plan

The top item is the same email that ranked last without the Frame. The project plan says the migration window gates Thursday’s cutover, and that date was confirmed to Northwind in writing. Read together, a scheduling question is a blocked deliverable.

The email was in both lists. Only the second one knew what it meant.

Priya wrote as if the reader shared her context, the way colleagues do. One rule told the agent where that context is written down; the other told it what to do once it had it. Neither is clever. Together they caught the one item that could have cost a client.

09

A Frame is maintained, not finished.

01

Use it

In real work.

02

Suggest

Send changes to the owner, not to a copy.

03

Revise

The maintainer is accountable for changes.

04

New version

Recorded in the history, visible to everyone.

ANTI-PATTERNS

The kitchen sink

Everything anyone ever knew, in one Frame nobody reads.

The aspirational Frame

Rules describing who you'd like to be, not what you do.

No maintainer

Nobody owns it, so nobody fixes it when it goes stale.

Tasks in disguise

Task instructions dressed up as standing context.

Frame Spec v0.2, in full.

Everything above is a way of working. This is the contract. Point an agent at this page and it knows how to read, write and use frames.

Required Fields

Every v0.2 Frame should have type, name, description, and visibility.
type

This must be:

Yaml

type: frame

or, to specify which version of the Frame Spec the Frame conforms to:

Yaml

type: frame [0.2]

This is the minimal explicit hook that tells an AI system or surrounding implementation that the file is intended to be handled as a Frame rather than as generic Markdown. The bracketed spec version is optional but recommended.

These are the only two valid forms: frame, or frame [<major>.<minor>].
The bracketed token names the spec conformance family as major.minor. Spec releases themselves are identified by three-part version numbers such as v0.2.0. Patch releases clarify wording without changing conformance requirements, so the patch component never appears in the type token: frame [0.2] declares conformance with any v0.2.x release, while frame [0.2.0] is not a valid value.
name
Short human-readable name for the Frame.
description

One or two sentences describing what the Frame is for and when it should be used.

visibility

Suggested values:

  • private
  • internal
  • shared
  • public

Recommended Fields

These are not required in v0.2, but they are encouraged: version, scope, maintainer, inherits.
version
The current version of this Frame.

Yaml

version: 0.1.0

This tracks the Frame’s own revision history, not the spec version. Authors should update this when the content of the Frame changes.

version is suggested rather than required in v0.2 so people can start using Frames without first committing to a versioning scheme. When a Frame is expected to be shared, revised, or referenced over time, including version is strongly recommended.
scope
A short description of where this Frame applies. Examples: company, department, project, partner, personal.
v0.2 does not require a formal scope grammar.
maintainer
The person, team, or organization that maintains the Frame.
inherits

One or more parent Frames that this Frame extends. May be a single value or a list.

Yaml

inherits: company-core

Yaml

inherits:
– company-core
– department-engineering

Values should be references that an implementation can resolve: typically a file path, a Frame name, or a URI. The spec does not require a specific resolution mechanism.

Body Content

After the frontmatter, the rest of the file is normal Markdown. The body should contain the context the Frame is meant to carry. Typical content may include:

Frames are intended to be loaded as system context for AI assistants, where tokens are at a premium. Authors should keep body content concise: prefer short bullets over long prose, omit boilerplate, and include only the guidance that would actually change how work is done. A Frame that is too long to read quickly is too long to be useful.

v0.2 does not require a fixed section taxonomy.

Inheritance

A Frame may declare that it inherits from one or more parent Frames using the inherits field.

Semantics

1.

Inheritance must be explicit.

A Frame only inherits what it declares.

2.

A child Frame extends its parents.

All parent guidance applies unless the child overrides it.

3.

The child takes precedence.

Where parent and child guidance conflict, the child wins.

4.

Parents are read in order.

When multiple parents are listed, earlier entries have lower precedence than later entries. The child always has highest precedence.

5.

Inheritance is not transitive by default.

If A inherits B and B inherits C, an implementation may resolve the full chain, but is not required to.

Because transitive resolution is optional, the same Frame may behave differently across tools. Implementations should disclose whether they resolve inheritance chains transitively, and authors should not rely on transitive resolution unless a specific tool guarantees it.

What inheritance means in practice

When a Frame with inherits is activated, an implementation should:

1.

Resolve and load the parent Frame(s).

2.

Present the combined guidance to the AI assistant, with the child’s content taking precedence on any point of conflict.

The simplest valid implementation is concatenation: parent content first, then child content, with a note that later content overrides earlier content.

Scope and inheritance

Inheritance typically flows from broader to narrower scope: company → department → team → project. This is a convention, not a requirement. A Frame may inherit from any other Frame regardless of scope.

Minimal Example

MD


type: frame [0.2]
name: Editorial Style Guide
description: Shared guidance for clear, consistent external writing.
visibility: shared

# Editorial Style Guide

## Goals

– Be clear, direct, and credible.
– Avoid hype and overclaiming.

## Terminology

– Prefer “Frame” over “alignment file”.

## Style

– Use calm, explanatory language.
– Make important assumptions explicit.

This example is intentionally minimal. It uses only the fields required by v0.2.

More Complete Example

MD


type: frame [0.2]
name: Engineering Documentation Style
description: Writing guidance for engineering documentation that extends a broader editorial style guide.
visibility: internal
version: 0.1.0
scope: department
maintainer: engineering enablement
inherits: editorial-style-guide

# Engineering Documentation Style

## Style

– Use precise technical language when writing for engineers.
– Keep the calm, direct tone from the broader editorial guidance.
– Code examples are preferred over abstract descriptions.

This example includes several suggested fields from v0.2, including version, scope, maintainer, and inherits.

Inheritance example

In the example above, the engineering documentation Frame inherits the editorial style guide Frame. All parent guidance applies unless the child Frame overrides it. The child Frame narrows broad editorial guidance into conventions for engineering documentation.

What v0.2 Does Not Try To Define

v0.2 intentionally does not standardize:

Those may become part of later versions, but they should not block immediate use.

Because a Frame is loaded as system context, it can influence how an AI assistant behaves. Provenance and source verification are future-facing and are not defined in v0.2. Until they are, implementations and users should only load Frames from trusted sources and should not treat a Frame’s contents as verified.

Sharing

At a minimum, an implementation should be able to:

Expected Agent Handling

At a minimum, an implementation should be able to:

1.

Detect type: frame in the frontmatter.

2.

Read the remaining frontmatter as lightweight metadata.

3.

Read the Markdown body as contextual guidance for work.

4.

Apply that guidance when the Frame is made active by a user or system.

5.

When inherits is present, resolve parent Frames and combine their guidance with the child’s.
v0.2 does not require more advanced behavior such as transitive inheritance resolution, provenance validation, or canonical-source lookup.

Relationship To Future Work

This document is the current adopt-now spec. Future ideas such as richer identity, packaging, layering semantics, and application integration are tracked separately in the discussion docs.

We use cookies

We use cookies to improve your experience on this website. You may choose which types of cookies to allow and change your preferences at any time. Disabling cookies may impact your experience on this website. You can learn more by viewing our Cookie Policy.