How far are Foyer, Memra, Bott and Fynn from the proposed SDLC loop?

Short answer: the ingredients are real and unusually well aligned, but the end-to-end loop described in One sentence to shipped feature is not yet a productized system. I would rate us about 55-60% structurally ready, with the hardest missing layer being the frozen, testable spec contract that moves cleanly from Foyer into Bott and back into Memra/Foyer after production learning.

Prepared 2026-07-28 from the attached markdown and repository evidence visible for axelerant/foyer, axelerant/memra, axelerant/bott, and axelerant/fynn.

55-60%

Readiness estimate

Strong foundations, partial integration, missing orchestration contract.

Present Memra context substrate, citation discipline, entity model, operational corpus plan, Bott agent/task harness, Foyer proposal workspace, Fynn people platform.

Partial Foyer-Memra workspace integration, channel/repo/project mapping, review/reporting workflows, human gates.

Missing Machine-readable feature spec lifecycle, spec-to-build API, acceptance-criteria test mapping, post-deploy measurement loop, spec defect diagnosis workflow.

What the attached markdown is really asking for

The brief is not just asking for four products to coexist. It describes a closed SDLC control loop:

Loop segment	Expected behavior	Primary owner
Intake and discovery	A vague client sentence becomes a grounded, gap-aware discovery flow.	Foyer + Memra
Spec	Requirements become frozen, versioned, machine-readable acceptance criteria.	Foyer + Memra
Plan/build/review/test/deploy	An agent turns the spec into code, PRs, reviews, tests, release notes, and deployment.	Bott
Watch/measure/report	Production signals become alerts, client reports, and recommendations.	Bott + Memra + Foyer
Diagnose and re-enter	The system distinguishes code defects, spec defects, and changed client intent, then restarts at the right phase.	Human gate + Memra/Foyer
Human capability	People get better at judgment, spec quality, AI fluency, and feedback.	Fynn

Evidence from the repos

Memra: strongest foundation

Memra is explicitly framed as the organizational substrate: it records, indexes, and synthesizes people, accounts, opportunities, engagements, partners, content and conversations, exposes that context through MCP/REST, and includes a learning loop for retrieval gaps and human-reviewed fixes. The Phase 1 spec also defines entity resolution, indexed shared and operational corpora, citation discipline, insufficient-evidence behavior, and retrieval quality checks.

That maps directly to the markdown's "memory" role and supports Phases 1, 2, 3, 9, 10 and 11. The foundation is ahead of the other pieces because it already treats stale/missing context, citations, entity identity, and learning loops as first-class concerns.

Foyer: good target surface, integration still Phase 2

Foyer's README describes an opportunity workspace that drafts proposal and pitch blocks from evidence, with citations back to source material. The Memra Phase 2 integration spec says Foyer becomes a consumer of Memra, with per-opportunity workspace corpora, isolated workspace indexing, Slack/Drive/HubSpot binding, and auto-populated workspace suggestions.

This strongly supports discovery and proposal authoring. It does not yet prove the proposed feature-spec lifecycle: frozen versions, acceptance-criteria schemas, handoff to Bott, spec mutation rules, and re-entry semantics need to be designed as a product contract, not just prose.

Bott: right agent harness, missing productized spec runner

Bott is described as a multi-tenant Slack engineering agent that maps projects to Slack channels and GitHub repos, runs agentic tasks, reviews PRs, raises PRs, triages issues, refreshes context, and keeps audit records. Its architecture has a task queue, worker loop, crash recovery, scheduled context refresh, task event logging, tool-call blobs, and Slack-native command handling.

That is exactly the workshop substrate for Phases 4-8. The missing part is not general agency; it is a stable spec ingestion and execution protocol: accept Foyer spec vN, produce plan, require human approval, implement, open PR, review against the spec, map tests to criteria, and return structured outcomes to Foyer/Memra.

Fynn: adjacent and mostly sufficient for the people loop

Fynn is explicitly a single-workspace Slack bot for team-care rituals: check-ins, feedback, learning, AI-native career growth, signals, hiring, HRIS, IT and hardware. The attached markdown correctly places it beside the delivery chain rather than inside it.

For the target loop, Fynn does not need deep runtime integration immediately. The useful first integration is evidence flow: feed spec-quality signals, review patterns, AI-fluency behaviors, and learning needs into Fynn so the humans doing discovery, ratification, review, and interpretation improve over time.

Phase-by-phase readiness

Phase	Readiness	Why	Main gap
1. Ask arrives	60%	Foyer workspace plus Memra entity/history model fit well.	Intake object needs to distinguish feature/project/support ask and bind to account/opportunity automatically.
2. Discovery call	50%	Memra can ground call prep; Foyer can host opportunity context.	No confirmed discovery-question workflow with added/removed/confirmed buckets.
3. Spec	30%	The concept exists in the brief, but repo evidence points more to proposal blocks than executable specs.	Need spec schema, versioning, acceptance criteria, approval state, and change history.
4. Plan	65%	Bott can inspect repos and produce implementation plans.	Need formal plan object tied to spec ID/version and approval gate.
5. Build	70%	Bott already fits code generation and PR creation workflows.	Need deterministic spec-to-PR traceability and artifact return channel.
6. Review	75%	PR review is an established Bott behavior in Slack.	Review must explicitly check spec criteria, not only diff quality.
7. Test	55%	Existing repo CI and task execution provide the base.	Need acceptance-criteria-to-test mapping and report format.
8. Deploy	45%	Bott has deployment and release-adjacent primitives, but customer feature rollout is domain-specific.	Need environment contracts, approval gates, staged rollout controls, and release-note writeback.
9. Watch	45%	Memra operational corpus and Bott context refresh help; observability integration is not proven.	Need logs/metrics/Sentry/product analytics ingestion and diagnosis rules per feature.
10. Measure/report	50%	Bott can publish reports; Foyer can host client-ready artifacts in principle.	Need KPI schema per spec and Foyer portal publication flow.
11. Loop closes	25%	Memra has a learning-loop philosophy, but spec-defect diagnosis is not implemented as a lifecycle.	Need re-entry classifier: code defect -> Phase 4, spec defect -> Phase 3, changed intent -> Phase 2.

The real gap

The system is not blocked by LLM capability. It is blocked by product contracts between the platforms.

Right now the repos show: Foyer can become the front door, Memra can remember and cite, Bott can act, and Fynn can develop people. What is missing is the shared object model that lets them pass the same requirement through every phase without losing identity, version, approval state, evidence, and acceptance criteria.

What to build next

Milestone 1: Spec contract, no automation magic

Create a canonical FeatureSpec schema owned by Foyer/Memra: request, context citations, open questions, requirements, non-requirements, acceptance criteria, test oracle, owner, approval state, version.
Add spec versioning and immutable approved snapshots.
Add a human approval gate before Bott can consume the spec.
Success condition: a spec can be created, approved, versioned, and cited without any code generation.

Milestone 2: Bott spec runner

Add a Bott command/API that accepts FeatureSpec by ID and repo mapping.
Produce a structured implementation plan with file targets, test plan, unknowns, and rollback notes.
Require approval before code changes.
Open or update exactly one PR per feature spec.
Success condition: Foyer spec v1 turns into a Bott plan and PR with traceability back to the spec.

Milestone 3: Acceptance criteria as the review/test spine

Require every acceptance criterion to be machine-checkable or explicitly marked human-judged.
Have Bott produce a criterion-by-criterion test report after CI.
Have Bott review PRs against the spec, not just codebase conventions.
Success condition: a release decision can point to which criteria passed, failed, or required human review.

Milestone 4: Release and observation loop

Capture deployment state, rollout percentage, release notes, and production smoke checks.
Connect Sentry/logs/product analytics to the feature spec ID.
Generate post-deploy watch summaries and client-ready measurement reports.
Success condition: a shipped feature produces operational evidence tied back to its original spec.

Milestone 5: Re-entry diagnosis

Create the defect classifier: code defect, spec defect, or changed client intent.
Make spec edits create v2 rather than silently patching implementation.
Record lessons into Memra as reusable, cited organizational context.
Success condition: the system can explain why it is restarting at Phase 2, 3, or 4.

Suggested implementation shape

Shared IDs

Every artifact should carry feature_spec_id, spec_version, account_id, opportunity_id, repo, pr_number, and deployment_id where applicable.

State machine

Model the lifecycle explicitly: draft -> discovery_ready -> approved -> planning -> plan_approved -> building -> review -> testing -> staged -> live -> observing -> measuring -> needs_reentry | closed.

Evidence policy

Use Memra's citation discipline for every factual input, and treat insufficient evidence as a normal state that blocks approval until resolved.

Human gates

Keep gates exactly where the markdown places judgment: approve discovery framing, approve spec, approve plan, judge review findings, approve release, decide re-entry.

Risks

Spec theater: If specs are prose documents, the loop will look right but fail automation. Acceptance criteria need typed fields.
Unowned integration: Foyer, Memra and Bott each make sense alone. The loop needs one owner for cross-platform contracts.
Over-automation of judgment: Phase 11 is deliberately human-opened. Automating the diagnosis too early will create bad re-entry decisions.
Observability gap: Shipping is not the end of this architecture. Without production metrics tied to spec IDs, phases 9-11 become manual reporting.
Data contamination: Foyer workspaces need strict opportunity isolation. The Phase 2 plan calls this out; it should remain non-negotiable.

Bottom line

We are closer than a greenfield team because each platform already owns the right kind of responsibility. Memra has the context substrate, Foyer has the client/opportunity surface, Bott has the agentic engineering harness, and Fynn has the people-development surface.

But the attached markdown describes a closed lifecycle, not a set of capabilities. To achieve it, the next investment should be boring and precise: define the spec object, make it versioned and testable, wire Bott to consume it, and make post-deploy learning update the spec rather than disappear into chat.