How we build
Tapestry.

Product judgment, design, agents and a lot of handoffs. An inside look at how a decision becomes something you can use.

The workflow behind TapestryFrom product decisions to released software

The tools matter.
So does everything between them.

Tapestry is built around a relationship problem: useful context can be somewhere in your history and still be missing when you need it.

Building it means keeping that purpose intact across product choices, design, code and the way we explain what ships.

The workflow behind the work.

Explore who owns each stage, what it produces and what the next handoff needs.

A clear decision before more work.

Andrew chooses the relationship problem, the intended outcome and the tradeoffs. The specification carries those decisions into the next stage.

Responsibility
Andrew · product judgment
What moves forward
A scoped decision and acceptance criteria
The next handoff

Record the objective, boundaries and unresolved decisions in the work brief.

This is the core operating workflow. Specific checks and approval boundaries depend on the task. The case study below shows one application.

Explore the separate case study

Work keeps moving across the day.

Scoped agents, scheduled workflows and automated checks carry work between decisions—from implementation and release to content preparation and distribution.

A workflow illustration. Independent work, connected by clear handoffs.

Scoped work

Product tasks in Linear. Approved briefs for GTM.

Clear scopeBoundariesNext check
  • Build

    Scoped agents implement bounded changes.

  • Review & checks

    Separate checks return findings and evidence.

  • GTM preparation

    Approved facts become drafts and creative.

Evidence & handoff

The change. The checks. The next decision.

Context travels with the work.

Waiting for a decision

Work that needs judgment pauses. Independent tasks can continue.

The lanes may run alongside one another. Every change follows its own dependencies.

An overnight workflow.

An example of how approved work can move from evening tasks to morning delivery.

Illustrative timing · 6:30 p.m.–8:00 a.m. Eastern

  1. 6:30 p.m.Approved work enters the queue.

    Product scope and campaign direction are set.

    Decision recorded
  2. 8:00 p.m.Scoped agents build and prepare.

    Independent implementation and GTM tasks progress.

    Agent execution
  3. 10:00 p.m.Checks run. Findings return.

    Tests and selected review passes inform the next step.

    Automated checks · selective review
  4. 12:30 a.m.Work reaches its approval gates.

    Authorized work proceeds; unresolved decisions wait.

    Approval gate
  5. 8:00 a.m.An approved newsletter is sent.

    The scheduler sends the prepared campaign.

    Scheduled delivery

Illustrative timing, not a recorded run or the current publishing schedule. Releases and sends follow their applicable approvals. Work that needs a decision waits.

Horizontal scaling

One direction. More work in parallel.

Work can outlast the session doing it. Linear holds the assignment and decisions; GitHub holds the implementation and checks. Hermes triggers Claude Code cloud sessions, and the TPM coordinates dependencies and exceptions. Independent builders can keep moving within their delegated authority.

Engineering example · parallel builder work

Example work in flight, not measured throughput, live agents or headcount.

Example engineering workstreams shown

Accountable owner · judgment

Direction becomes reusable context

  • Objective
  • Constraints
  • Authority
  • Acceptance criteria

Routing · Hermes profiles

Route scoped build work from Linear and trigger Claude Code cloud sessions. The work happens in the sessions.

Parallel execution

3 example workstreams in flight, each with its own context and checks

  • Product flow

    • Scope
    • Work
    • Checks
    • Evidence
  • Reliability

    • Scope
    • Work
    • Checks
    • Evidence
  • Platform work

    • Scope
    • Work
    • Checks
    • Evidence
Next handoff

Completed evidence

Available for the next handoff.

Judgment

Decisions & exceptions

Returned to the accountable owner.

Capacity grows by adding scoped workstreams. Releases and sends still follow their task-specific approval rules, and more workstreams do not mean proportionally more output.

The tools, and
the jobs they do.

Each tool has a role in the work. The handoff carries the context into the next one.

Linear

Work planning and agent handoffs

Scoped issues, acceptance criteria, dependencies and the evidence returned with each task.

Hermes profiles

Routing and session triggers

Rule-based profiles read scoped work in Linear and trigger cloud sessions. The building happens in Claude Code.

Claude

Claude

Product and engineering coordination

The TPM scopes assignments, evaluates evidence, handles exceptions and escalates reserved decisions.

Claude Code

Claude Code

Parallel builders in native cloud sessions

Builders work on scoped assignments in parallel through Claude Code on the web.

Figma / FigJam

Design decisions and interface states

Editable designs and agreed interaction details carry intent into implementation.

GitHub / Actions

Changes, checks and release gates

Branches and pull requests preserve the change; automated checks record what passed.

Greptile

Risk-based code review

Reviews selected pull requests with codebase context, returning findings for the builder to address before merge.

Codex

Independent review, when needed

A documented option for a separate review pass or implementation fallback.

Measurement also draws on Google Analytics, Search Console and DataForSEO. Review tools and checks vary with the task.

These tools support Tapestry’s development and marketing workflows. Product names and logos belong to their respective owners.

Case study: one release.

A small change puts the workflow in context. Follow one product choice from its specification to the beta release channel.

Released to beta · v0.2.53

A reminder should respect your attention.

A small setting makes a larger decision visible: meeting notices use ordinary priority by default. Time Sensitive delivery is a choice the member makes.

  • Off by default, including when older settings are loaded.
  • One clear switch: “Let meeting notices through Focus.”
  • Individual and grouped notices follow the same choice.

Available in the beta release channel on November 9, 2026.

Help me prepare. Respect my Focus.

Explore the delivery choice in this illustration.

Focus is on
Let meeting notices through Focus

Off: meeting notices use ordinary priority and follow your Focus settings.

DefaultOrdinary priority, by default

Tapestry uses ordinary notification priority. Delivery follows your macOS notification and Focus settings.

Illustrative interface, based on released behavior. This is not an app recording or a test of your Mac’s Focus settings.

Try the switch to see what changes.

  1. Choose the default

    Make interruption a deliberate choice. Record the behavior and exact interface language.

  2. Build the choice

    Add the setting, preserve older preferences and cover single and grouped notices.

  3. Check the change

    Correct a test-claim finding. Pass automated checks on the feature and release candidates.

  4. Make it available

    Include the change in v0.2.53 and publish the beta update configuration.

What the evidence shows: the change, automated checks and release publication. Manual checks on a Mac remained a follow-up in the handoff. This case does not claim adoption or a measured productivity gain.

One night, three AI builders.

Follow a recorded run from a failed CI drill to an automatic recovery, while other builders moved their own assignments forward.

Selected recorded activity · November 8–9, 2026 · Eastern time
Selected recorded activity, November 8, 7pm to November 9, 3am Eastern, across three Claude Code AI agents and Andrew. Builder B picks up the CI recovery fix at 8:35pm, raises a scope exception at 9:38pm, the TPM resolves it at 10:09pm after a 31-minute stop, a fresh session resumes the same pull request at 10:29pm, the fix merges at 12:16am and CI returns to the Mac mini automatically at 12:21am. Andrew approves process changes at 9:33pm and Builder A merges the process rule at 10:10pm, then a team-share notice at 11:25pm. Builder C corrects review findings at 11:00pm and merges the community screens at 2:09am, which lets Builder A start dependent work at 2:16am. Builder aliases used; recorded timestamps and event sequence preserved.Builder AAI agentBuilder BAI agentBuilder CAI agent7pm · Nov 8 · selected record begins8:35pmPicks up theCI recovery fix9:33pm · Andrew, founder (human)Approves process changes9:38pmRaises a scopeexception31-minute stop10:09pmTPM resolvesthe exception10:10pmProcess rulemerged10:29pmFresh sessionresumes the PR11:00pmReview findingscorrected11:25pmTeam-sharenotice mergedNov 912:16amFix merged12:21amCI back on theMac mini2:09amCommunityscreens merged2:16amDependentwork starts3am · Nov 9 · selected record endsReturnedthroughthe TPMDependency clearsMergedWork eventException raisedTPM decisionAndrew’s decisionCI restored
  1. 8:35pm, Builder B: Picks up the CI recovery fix.
  2. 9:33pm, Andrew: Approves process changes.
  3. 9:38pm, Builder B: Raises a bounded scope exception.
  4. 10:09pm, Builder B: TPM resolves the exception.
  5. 10:10pm, Builder A: Process rule merged.
  6. 10:29pm, Builder B: Fresh session resumes the same PR.
  7. 11:00pm, Builder C: Review findings corrected.
  8. 11:25pm, Builder A: Team-share notice merged.
  9. 12:16am, Builder B: Fix merged.
  10. 12:21am, Builder B: CI returns to the Mac mini automatically.
  11. 2:09am, Builder C: Community screens merged.
  12. 2:16am, Builder A: Dependent work starts after the community merge.

Spacing schematic, not to time scale.

Selected records from Claude TPM’s audit of issue comments, commits and CI records. Andrew participated. Not a typical night or a productivity benchmark.

Markers show selected events, not continuous activity. Times shown to the minute. The Mac mini is macOS CI hardware; GitHub Actions orchestrates CI.

Builder aliases used; recorded timestamps and event sequence preserved.

What this run shows

  • A decision resolved by the TPM

    One scope exception was answered within the TPM’s delegated authority.

  • A new session, the same work

    A fresh builder session resumed the same pull request from recorded state.

  • A dependency handed forward

    After one builder’s change merged, another started the dependent work.

Want to learn more?

Building a company, investing or exploring a similar workflow? Ask Andrew for a walkthrough.

  • Agent coordination
  • Product & design
  • Release workflows
  • Growth execution

Start a conversation.

Email Tapestry with your role and the workflow you’d like to explore.

Ask about a walkthrough

hello@tapestryprm.com

Opens your email app. Please don’t include confidential information or personal relationship records.

Request product access

How Tapestry moves from idea to release.