Layer type
Orchestration memory
Planned Build Layer / Roadmap
Build memory and AI orchestration for VS Code.
Tanya Build Layer is the next pl8ypus infrastructure build: a repo-aware orchestration layer that retrieves project truth from vector memory, generates controlled task packets for Claude Code and Codex, and captures lessons learned after each build session - operated from a VS Code chat window.
This is the next strategic build layer after the Audience Finder AI milestone. Not in production today - roadmap and architecture definition stage.
Interface
VS Code chat window
Memory type
Vector-based retrieval
Stage
Roadmap / Architecture
The Problem
Multi-tool AI builds without memory cost time, tokens, and accuracy.
Every session with Claude Code or Codex starts from zero unless you re-explain the project. Long builds accumulate context debt: repeated explanations, wrong-surface edits, route confusion, and token waste that compounds across every session.
Memory loss
Context resets every session
Project rules, deployment constraints, known failures, and architecture decisions disappear when a session ends. The next session re-explains from scratch.
Token waste
Repeated explanations burn context
Pasting project files, re-explaining routing conventions, and describing deployment rules every session consumes tokens that should go toward actual build work.
Execution errors
Context drift causes wrong-surface edits
Without a reliable source of truth, AI tools edit the wrong file, target the wrong route, or miss known forbidden paths - avoidable errors that take time to undo.
Pain points experienced directly
- Context loss between sessions - project rules forgotten
- Repeated explanations to Claude Code and Codex
- Wrong file or wrong surface confusion
- Route confusion - editing client-side when change belongs server-side
- Inconsistent source of truth between sessions
Operational friction that compounds
- Long build sessions with too much manual orchestration overhead
- Token burn from re-explaining project rules and deployment constraints
- Avoidable implementation errors from context drift
- Slow handoff from planning decisions to execution
- Lessons learned from one build not reaching the next
What Tanya Build Layer Is
Repo-aware memory and controlled task generation for AI builds.
Tanya Build Layer is not a chatbot or a prompt wrapper. It is a build operating layer: a VS Code chat window backed by vector-based project memory, a repo truth layer, a task packet generator, and a lessons-learned writeback system. It sits between the builder and the AI tools to reduce friction, context loss, and execution errors.
Interface
VS Code chat window
A sidebar or panel in VS Code where you can ask questions, retrieve project context, and generate build packets without leaving the editor or switching tools.
Memory
Vector-based project memory
Project rules, deployment decisions, known failures, architecture notes, and lessons learned are stored as vector embeddings and retrieved semantically when relevant.
Context
Repo-aware truth layer
The system can surface repo maps, project rules, deployment constraints, forbidden paths, and current build state so every task packet starts from accurate project truth.
Packets
Controlled task packet generation
Instead of open-ended prompts, the layer generates structured task packets for Claude Code or Codex: allowed files, scope constraints, validation steps, and expected return format.
Writeback
Lessons-learned capture
After each build session the system captures what worked, what failed, what was decided, and why - writing back to project memory so the next session starts smarter.
Control
Build control and review loop
The builder stays in control. Tanya Build Layer generates packets and retrieves context - it does not execute autonomously. The human approves, reviews, and decides.
Architecture
A seven-layer build stack from chat to execution to memory writeback.
The operating flow: Greg sends a build request through the VS Code chat window. The vector memory layer retrieves relevant project truth. A controlled task packet is generated and sent to Claude Code or Codex. Output is reviewed, validated, and lessons are written back to memory.
Click to enlarge architecture
Tanya Build Layer end-state architecture - VS Code chat, vector memory, controlled task packets, Claude Code and Codex execution, QA gates, and lessons-learned writeback.
01
VS Code chat window
The primary interface: a sidebar or panel in VS Code where the builder can query project memory, request context, and generate build packets without switching applications.
02
Project memory / vector layer
Stores project rules, architecture decisions, deployment constraints, known failures, and lessons learned as vector embeddings. Retrieved semantically based on the current task context.
03
Repo truth and rules layer
Repo map, file inventory, routing rules, forbidden paths, deployment targets, environment notes, and project-specific constraints surfaced before each task packet is generated.
04
Build packet generator
Generates structured task packets for Claude Code or Codex: task scope, allowed files, forbidden files, validation commands, expected output format, and return instructions.
05
Claude Code / Codex execution layer
The task packet is routed to the appropriate execution tool. Claude Code handles conversational build tasks; Codex handles structured code generation. Both receive tightly scoped packets.
06
QA / validation layer
Diff review, test runs, build checks, and human review of the output before any change is accepted. The builder approves output before it enters the working tree.
07
Lessons learned memory writeback
After a session, validated decisions, failure notes, and build outcomes are written back to the vector memory layer. The next session inherits this context automatically.
Business Case
Directional impact once the build layer is operational.
The following estimates are directional only - based on observed build friction and workflow patterns from current multi-tool builds, not proven financial results. They represent the opportunity this layer is designed to address.
Token reduction
30 - 50%
Estimated reduction from targeted context retrieval versus full file pasting and session re-explanation.
Repeated explanations
50 - 70%
Estimated reduction in repeated project rule and convention explanations across build sessions.
Execution errors
30 - 60%
Estimated reduction in context-drift errors: wrong file edits, routing mistakes, and forbidden-path violations.
Build cycle speed
20 - 40%
Estimated improvement in build cycle time by reducing session warm-up and mid-session context recovery overhead.
Session recovery
40 - 60%
Estimated improvement in recovery speed after a session break, context window reset, or tool switch.
Knowledge retention
High
Lessons learned writeback means build decisions, failures, and workarounds persist across sessions and projects rather than being lost.
All figures are directional estimates based on current build workflow observation, not measured or guaranteed outcomes.
Qualitative operational benefits
- Lower cognitive load - less manual context management per session
- Tighter control of Claude Code and Codex via scoped task packets
- Better reuse of lessons learned across builds and sessions
- Less drift between architecture decisions and implementation reality
Build system benefits
- Safer production debugging with repo truth always available
- Clearer audit trail of build decisions and AI task packets issued
- Faster onboarding into any repo through memory-backed context retrieval
- Reduced token spend across multi-session builds and multi-project workflows
Roadmap
Six phases from memory foundation to advanced build control.
Current stage: roadmap / architecture definition
Phase 1
Memory foundation
Local memory structure and vector search prototype
- Local memory structure and file format definition
- Repo truth files - project rules and conventions
- Lessons learned store and write format
- Vector search prototype for context retrieval
Phase 2
Build packet engine
Claude Code and Codex task packet generation
- Claude Code packet templates with scope, allowed files, and forbidden files
- Codex packet templates with structured code generation constraints
- Allowed and forbidden file logic per task type
- Validation command templates and return format specifications
Phase 3
CLI / local operator
Tanya CLI for local build operations
- Tanya CLI for terminal-based task and memory operations
- Task export to Claude Code or Codex
- Memory query from the terminal
- Session report capture and writeback
Phase 4
VS Code chat window
VS Code sidebar with project memory and task generation
- VS Code sidebar extension with chat interface
- Project selector and current repo awareness
- Memory search and context retrieval from chat
- Task packet generation from natural language requests
Phase 5
Orchestration and QA
Diff review, QA gate suggestions, and milestone tracking
- Diff review assistance after Claude Code or Codex runs
- QA gate suggestions based on task type and project rules
- Build review summaries for session handoff and audit
- Milestone tracking against project goals
Phase 6
Advanced build control
Richer memory graph and multi-project orchestration
- Richer memory graph with relationship mapping between decisions
- Stronger retrieval with ranking and relevance weighting
- Multi-project context switching and cross-project lesson reuse
- Deeper orchestration when safety and control are proven
Use Cases
Practical applications across current pl8ypus builds.
Build 01
Audience Finder AI build control
Store Audience Finder architecture, Cloudflare Worker rules, KV patterns, scoring logic, and deployment constraints in memory. Generate packets for new features without re-explaining the entire system each session.
Build 02
Translation AI orchestration
Capture the Translation AI payload structure, language agent rules, QA gate logic, and terminology protection patterns once. Retrieve them whenever build work touches this system.
Build 03
Marketing Intelligence AI build memory
Retain the architecture decision trail, ingestion governance rules, data model choices, and selected option context across the Marketing Intelligence AI build without re-reading the full page.
Workflow
VS Code extension build workflow
When building VS Code extensions or tooling, Tanya Build Layer holds the extension API conventions, manifest rules, known compatibility issues, and testing patterns so each session starts with accurate context.
Portfolio
Reusable AI delivery process
Tanya Build Layer makes the pl8ypus build method reusable: consistent task packet formats, shared project truth files, and lessons from one build improving the next build's starting position.
Guardrails and Scope
Designed for human-controlled build orchestration first.
Tanya Build Layer is a memory and coordination layer, not an autonomous execution system. These boundaries are intentional and will remain in place through the early phases.
What it is not designed to do yet
> Not autonomous production control
> Not blind code execution without human review
> Not uncontrolled secret or credential handling
> Not unrestricted multi-agent loops
> Not a substitute for the builder's judgement
What it is designed to do
> Retrieve accurate project context on request
> Generate scoped, reviewable task packets
> Reduce token waste and repeated explanations
> Capture and surface lessons learned
> Keep the builder in control at every step
Business Value
Turns AI coding into a repeatable delivery system.
Tanya Build Layer matters beyond internal efficiency. It represents a shift from one-off AI coding to a structured, repeatable delivery method - the kind of operational discipline that separates a serious AI build practice from tool experimentation.
Delivery consistency
Repeatable AI product delivery
Turns one-off AI coding sprints into a consistent delivery system with project memory, controlled execution, and captured lessons. The method improves with every build rather than resetting.
Risk reduction
Safer AI product shipping
Reduces the risk of wrong-surface edits, context drift errors, and missed deployment constraints when shipping AI products. Controlled task packets replace unchecked open prompts.
Enterprise build quality
Consistent quality across complex builds
Improves consistency across complex enterprise builds by keeping architecture decisions, deployment rules, and known failure patterns available throughout the build lifecycle.
Knowledge capture
Tacit knowledge made reusable
Converts tacit build knowledge - decisions, workarounds, failure patterns, routing rules - into reusable system knowledge that survives session breaks, context resets, and tool switches.
The pl8ypus build practice
Stronger practice, not just better tools
Tanya Build Layer strengthens the pl8ypus AI build practice: moving from isolated build sessions to a system that gets smarter over time, reduces friction with each build, and produces a cleaner evidence trail of how AI products were designed, built, and controlled. This is the difference between AI coding and AI delivery.
FAQ
Common questions about Tanya Build Layer.
What is Tanya Build Layer?
Tanya Build Layer is a planned repo-aware orchestration layer for AI-assisted builds. It provides a VS Code chat window connected to vector-based project memory, generates controlled task packets for Claude Code and Codex, and captures lessons learned after each build session.
Is this live today?
No. Tanya Build Layer is the next strategic build layer in the pl8ypus portfolio, currently at roadmap and architecture definition stage. It is grounded in real lessons from the Audience Finder AI and other pl8ypus builds but is not yet in production.
Does it replace Claude Code or Codex?
No. Tanya Build Layer coordinates Claude Code and Codex - it does not replace them. It sits above those tools as an orchestration and memory layer that generates tightly controlled task packets and reduces repeated explanations.
Why use vector memory for build orchestration?
Vector memory allows the system to retrieve relevant project truth, deployment rules, known failures, and repo context using semantic search rather than exact keyword matching. This means the right context reaches Claude Code or Codex without manually re-explaining the project at every session start.
How does it reduce token usage?
By retrieving only the relevant context chunks from vector memory rather than pasting entire files or re-explaining project rules from scratch each session. Tightly scoped task packets replace open-ended prompts, reducing the tokens Claude Code or Codex need to process.
Is this for internal use only or a future product?
Phase 1 through 3 are internal build infrastructure for pl8ypus. Later phases could evolve into a product or productised delivery methodology for AI-assisted software teams. The current priority is building a genuinely useful internal layer first.
Next Steps
Explore the build practice behind Tanya Build Layer.
AI Review
Explore Tanya Review
Tanya Review is the independent AI assessment of Greg's build practice. It covers the Audience Finder AI milestone, what was proven, and the emerging pattern behind Tanya Build Layer.
Read Tanya ReviewPortfolio
View current AI builds
The pl8ypus AI build portfolio shows the systems already in progress: Translation AI, Marketing Intelligence AI, and Audience Finder AI - the builds that Tanya Build Layer will serve.
View AI buildsContact
Talk to Greg about AI build systems
For serious conversations about AI build orchestration, vector memory systems, or building controlled AI delivery infrastructure.