secondme project constitution

status: draft v0
owner: core team
last updated: 2026-04-07
purpose: canonical alignment file for humans and ai agents

one-screen summary

• secondme is a private chief-of-staff operating layer for high-context principals.
• the core bottleneck is not lack of intelligence; it is fragmented context, weak compression, bad timing, and broken follow-through.
• the first wedge is an approval-ready cross-context briefing with prepared next actions.
• the first user filter is not hnw alone; it is complexity x stakes x agency.
• the product moat thesis is not model novelty; it is harness quality, memory quality, trust tuning, and continuity over time.
• we are not a research lab; we productize proven patterns, tools, and harnesses that work now.
• the system wins when it produces bounded leverage in reality, not when it sounds impressive in chat.
• doctrine is slow; bets are fast; raw chat never writes doctrine directly.

mission, north star, horizon

mission

preserve and extend continuity of agency for high-context principals.

north star

the user feels:

• i do not need to reconstruct my situation from scratch
• the system found the next best intervention before i asked
• it can act, but it knows when to stop

horizon

short horizon:

• win one workflow so strongly that users pull for it repeatedly

medium horizon:

• become the private operating layer across communications, planning, memory, and approvals

long horizon:

• become the chief-of-staff substrate around a principal, where human and ai operators inherit continuity instead of rebuilding it

why now

claim

this becomes buildable now because harness quality is improving faster than most products are adapting to it.

what we believe

• architecture around the model can create order-of-magnitude gains on hard tasks
• memory systems and context pipelines are becoming composable enough for product use
• users already feel the pain of context fragmentation more sharply than the pain of weak model IQ
• raw model access is commoditizing, which increases the value of workflow shape, trust, and continuity

what is strong vs weak

strong:

• external benchmark evidence and internal doctrine both point to harness > raw model delta
• custdev and synthesis both point to context management as the recurring pain

weak:

• any universal numeric claim like 1000x better is still too loose for our workflow and should not be treated as doctrine
• benchmark wins on arc-like tasks do not automatically transfer to principal workflows without replication

who this is for

primary filter

the true user filter is:

• complexity
• stakes
• agency

likely early users

• founders with multiple live fronts
• investors and portfolio operators
• wealth-adjacent principals with fragmented high-stakes context
• operators who already feel the cost of dropped continuity

not for

• low-context casual assistant use
• users who mainly want entertainment, companionship, or generic chat
• teams seeking a broad multi-agent platform before a sharp workflow exists

core pain

the recurring failure mode is:

1. context lives across chats, docs, notes, calendars, tasks, and people
2. the principal repeatedly reconstructs the same situation by hand
3. timing slips and follow-through degrades
4. delegated work loses context and identity
5. assistants sound helpful but fail the trust test

why opencode alone does not solve this

• it is still too session-shaped and operator-heavy
• memory continuity is weak unless someone constantly curates it
• cross-context synthesis is possible, but not packaged into a stable operating loop
• maintenance burden is still high enough to kill adoption for many users

first wedge and first wow

first wedge

approval-ready cross-context briefing for one principal.

first wow

the user connects several high-context surfaces and gets:

• what changed since the last checkpoint
• what matters now across projects, people, and deadlines
• what is blocked or drifting
• what draft, recommendation, or action is already prepared
• why this is the right next intervention for this person specifically

design rule

if the first wow requires a giant setup, deep manual curation, or lots of explanation, it is not the first wow.

v1 product scope

first wow and v1 are related but not identical.

first wow is the user outcome

• the user experiences prepared clarity and bounded leverage

v1 is the minimum system that can reliably produce that outcome

v1 should likely include:

• ingestion from 2-3 high-context surfaces
• inspectable memory with promoted summaries, not only raw recall
• one principal profile with preferences, priorities, and active campaigns
• briefing generation on a repeatable cadence
• approval boundary for all meaningful outbound actions
• prepared drafts or recommendations attached to the briefing
• outcome logging so the next cycle starts from updated reality

v1 should likely exclude:

• broad app marketplace behavior
• open-ended autonomous execution
• elaborate personality surfaces
• custom model training as a prerequisite

product invariants

• the harness is the product
• scaffolding > model
• chief of staff > chatbot
• inspectable memory > opaque magic
• continuity quality > response quality
• trust is part of utility
• proactivity is required
• one correct intervention > twenty plausible suggestions
• small adaptive wins > giant demos
• self-improvement must happen through observed outcomes, not fantasy self-critique
• build from proven working components before inventing net-new science
• the system should be theoretically shippable by a small team in weeks, not dependent on a research-lab burn rate

design principles

product principles

• start with one painful workflow, not category breadth
• optimize for approval-ready action, not insight theater
• reduce maintenance overhead aggressively
• earn more agency through repeated small wins
• preserve principal-specific identity and decision style

system principles

• prefer proven architectures over frontier novelty by default
• use existing strong harnesses and patterns as building blocks
• memory should be inspectable, layered, and promotable
• orchestration should be policy-aware, not just state-aware
• permissions and blast radius shape architecture from day 1
• delta updates beat full-context reload theater

operating principles

• doctrine is slow; bets are fast
• evidence outranks eloquence
• every bet needs a next test and a kill condition
• raw live channels do not update doctrine directly
• if the workflow is not frozen, architecture claims stay provisional

self-improvement loop

this system should improve by closing loops on real outcomes.

required loop

1. propose a bounded intervention
2. route through the right approval boundary
3. observe what the user accepted, rejected, or edited
4. write back preference, outcome, and confidence signals
5. adjust future action selection, not just future wording

anti-patterns

• self-improvement as pure prompt self-reflection
• claiming learning without changed behavior
• adding autonomy before we can explain why the last action worked

trust and agency ladder

trust should be graduated, not binary.

day 1

• ingest
• summarize
• prepare drafts
• recommend next actions

after proof of value

• schedule or execute reversible low-risk actions with approval
• operate on scoped channels with strong audit trail

only after deep trust

• higher-frequency delegation
• broader channel coverage
• narrower approval loops for pre-cleared action classes

hard rule

no irreversible or identity-sensitive action should be hidden behind “smart automation.”

business model posture

the business model should follow the trust ladder.

likely shape

• low-friction entry through obvious proof of power
• paid layer for security, reliability, support, and managed setup
• increasing value through deeper continuity, not through feature count

pricing logic

pricing likely tracks:

• stakes of dropped continuity
• trust posture
• setup and maintenance relief
• depth of delegated operating surface

weak points

• willingness to pay is still not evidenced strongly enough
• the split between software margin and service/setup margin is still open

proven harness map

these are not canonical dependencies yet. they are a working map of strong external patterns and candidate components.

rule for this table

every harness card should answer:

• what proof exists
• what layer it solves
• what we borrow
• what we reject
• what evidence would cause promotion into the canonical stack

inspiration map

these are not implementation dependencies. they are directional sources of truth.

active bets and kill conditions

• bet: context management is the core product, not one feature among many
• next test: collect concrete recent failures caused by fragmented context
• kill condition: users mostly describe generic drafting or automation pain instead
• bet: the first wow is a cross-context approval-ready briefing
• next test: produce live briefing artifacts that change user behavior
• kill condition: users find them interesting but not action-shaping
• bet: the wedge is complexity x stakes x agency, not hnw alone
• next test: compare urgency and pull across wealth-adjacent and non-wealth high-agency users
• kill condition: deployment and trust constraints tied to wealth dominate the buying logic
• bet: trust requires a ladder, not one deployment mode
• next test: capture what users allow at day 1, day 30, and after proof
• kill condition: one posture dominates and the ladder adds confusion
• bet: harness quality matters more than raw model delta for this workflow
• next test: compare raw model vs harnessed flow on the frozen briefing workflow
• kill condition: the harness does not win clearly on outcome quality, trust, or revision count

non-goals

• being a general research lab
• building a generic multi-agent platform before one sharp workflow wins
• chasing model novelty as a strategy
• autonomy without clear permissions
• memory theater without inspectability
• category language inflation without new field evidence

how doctrine changes

doctrine update rule

this file should only change when one of these happens:

• repeated field evidence changes a core belief
• a workflow is frozen or killed
• a source has been promoted through the explicit ingestion pipeline
• a trust or architecture constraint becomes materially clearer

change protocol

1. record the new signal in the right source artifact
2. classify it as decision, hypothesis, objection, or open question
3. compare it against existing doctrine and active bets
4. update doctrine only if the change is durable enough to guide future work

hard boundary

raw chat, brainstorm sharpness, and elegant argument do not count as doctrine by themselves.