JT7
JT7 is an operator-first product platform and agentic architecture accelerator.
It is designed to help build product surfaces and agentic workflows that compress decisions, preserve trust, and keep a human operator in control.
Its first complete end-to-end product flow is JT7 Jobs: a focused job-search command system built around Today’s Plan, next-best actions, recruiter visibility, follow-up timing, and evidence-backed execution.
What JT7 Is
JT7 is not just a single app, bot, or workflow.
JT7 is a layered product platform that combines:
- operator-facing product surfaces
- reusable workflow logic
- bounded agentic orchestration
- durable memory and decision context
- trust-aware runtime and persistence patterns
The goal is not generic autonomy.
The goal is to accelerate the creation of practical, high-trust agentic products.
Product Positioning
JT7 should be understood in two connected ways:
1. A product platform
JT7 provides the architecture, logic, state model, runtime seams, and product patterns needed to build focused operator-first products.
2. An agentic architecture accelerator
JT7 is meant to make it faster to design and ship product experiences where:
- agents assist with workflow execution
- humans retain review and control
- evidence and trust boundaries stay visible
- orchestration serves a real surface, not abstract automation theater
JT7 Jobs: The First End-to-End Flow
JT7 Jobs is the first full product flow built on JT7.
It is the current proof point for the platform because it connects:
- real signals
- workflow logic
- trusted state
- operator actions
- a product surface
- persistence and audit trails
JT7 Jobs is the first wedge, not the limit of JT7.
It proves the architecture through one concrete painkiller workflow before broader extraction.
Extensibility as a Core Pillar
Extensibility is a foundational part of JT7’s purpose and architecture.
That does not mean premature platformization.
It means JT7 should be built so validated patterns can be reused across future surfaces and workflows.
JT7 is intended to support expansion across:
- new operator-facing product surfaces
- new workflow domains
- new bounded agents and handoff roles
- new orchestration modules
- new runtime adapters and persistence paths
The rule is: prove value in a real flow first, then extract the reusable layer cleanly.
Strategic Hierarchy
JT7 evolves in three layers:
1. Painkiller product first
Ship JT7 Jobs as a daily-useful workflow product.
2. IP / framework extraction second
Extract reusable logic and patterns from proven usage.
3. Platform infrastructure third
Generalize infrastructure only after repeated validated patterns emerge.
Product Layers
JT7 currently spans several product layers.
1. Strategy and control layer
Defines mission, roadmap, decisions, current state, and product doctrine.
Key areas:
MISSION.mdCURRENT.mdMEMORY.mdDECISIONS.mdROADMAP.mdDESIGN.mdskills/agents/products/docs/strategy/docs/tickets/
2. Architecture layer
Defines the composable system model: artifacts, modules, skills, agents, and contracts.
This is where JT7’s extensibility lives structurally.
It separates:
- artifacts as durable truth/context
- modules as reusable capabilities
- skills as execution guardrails
- agents as operating roles
Key areas:
modules/skills/agents/- architecture and contract docs under
docs/
3. Runtime and orchestration layer
Runs ingestion, synchronization, scheduled passes, workflow execution, and bounded agentic logic.
Key areas:
job-search-ui/scripts/job-search-ui/runtime/
4. Truth and persistence layer
Preserves trust across live state, local mirrors, history, and external access.
Current trust model:
- Google Sheets = canonical live operational truth
- JSON / CSV mirrors = local runtime reflections and evidence
- git / GitHub = versioned history
- Google Drive = mirrored artifact access
- markdown = product, architecture, memory, and audit context
5. Product surface layer
Presents operator-facing applications where workflow value becomes usable.
Current surfaces include:
job-search-ui/ for JT7 Jobs- additional product surfaces such as
mqi-demo/ for adjacent explorations
6. End-to-end workflow layer
Connects the layers above into a real product loop.
JT7 Jobs is the current example of this layer in action:
signal -> workflow logic -> trusted state -> operator action -> product surface -> persistence
Current Execution Focus
The active execution focus is still Layer 1 — JT7 Jobs.
Near-term priorities:
- keep JT7 Jobs centered on daily operator usefulness
- package the onboarding slice cleanly
- preserve the existing trust and runtime baseline
- avoid broad refactors that do not improve the product loop
- keep extensibility additive and grounded in validated patterns
Core Product Principles
Everything in JT7 should reinforce:
- decision compression
- operator clarity
- workflow visibility
- evidence-backed state
- human-in-the-loop control
- additive extensibility
- high-trust agentic behavior
Important Paths
- Root project:
/jt7/.openclaw/workspace
- JT7 Jobs app:
/jt7/.openclaw/workspace/job-search-ui
- Strategic roadmap:
/jt7/.openclaw/workspace/ROADMAP.md
- Product thesis:
/jt7/.openclaw/workspace/product/thesis.md
- Strategic context:
/jt7/.openclaw/workspace/product/JT7_Strategic_Operating_Context.md
- Runtime task state:
/jt7/.openclaw/workspace/job-search-ui/runtime/jt7_tasks.json
- Runtime schedule state:
/jt7/.openclaw/workspace/job-search-ui/runtime/jt7_scheduler.json
- Runtime chain runner:
/jt7/.openclaw/workspace/job-search-ui/scripts/run_jt7_chain.py
Guardrails
Do not:
- mistake extensibility for permission to generalize too early
- broadly refactor working systems without clear product value
- build generic infrastructure before a workflow proves the need
- let agentic complexity outrun operator usefulness
- hide trust boundaries behind automation language
Do:
- keep JT7 Jobs as the proving ground
- extract reusable layers only from validated patterns
- preserve additive seams where possible
- tie orchestration to a real product surface
- keep human review, evidence, and state trust visible
