Fundi BoraKazi bora, bei bora — better work, better price.

The problem: skill is trapped, not absent

A jua kali fundi learned the trade by apprenticeship — watching, copying, improvising. What most never had is a senior: someone who looks at a finished piece and says "the gap in that joint is because your saw drifts; here's the ten-minute habit that fixes it forever."

The result is a specific, fixable failure pattern: producers repeat the same manufacturing errors for years — not because they can't improve, but because nobody ever closed the loop between the defect and its cause. Meanwhile the market punishes them twice: returned or discounted pieces now, and commodity prices forever, because they can't credibly claim quality (see the Kagua brief for the demand-side half of this story).

Who it's for, and the conditions on site

Primary persona

Yusuf, 28, fundi in the Gikomba furniture cluster, Nairobi. Six years in the trade, two casual workers, about eight pieces a month — stools, tables, bed frames. Owns hand tools and a worn No. 4 plane; borrows a neighbor's circular saw on Saturdays. Loses money two ways: a piece comes back for repair (his cost), and buyers knock his prices down because his finish quality is inconsistent. He wants to charge KSh 500 more per piece and have nothing come back. He voice-notes more than he types, in Swahili-English mix.

Site conditions specific to the producer side

Breaking it down: from verdict to coaching loop

Kagua answers "should I buy this?" Fundi Bora answers "why did this happen and what do I change?" Same eyes, different brain: the assessment engine is shared; everything downstream of the defect list is new.

The diagnosis chain is the differentiator

Every defect gets traced upstream until it hits something the fundi can change:

Note what the interventions have in common: two of three cost nothing. The model's job is not to sell tools — it's to find the cheapest change that removes the cause. Tool recommendations appear only when they beat every zero-cost alternative, and always with price and payback.

Profile & memory design

The profile: context the agent must never violate

Collected in a ten-minute onboarding, then maintained by the agent. The tool inventory has a deliberately low-friction path: photograph your bench and wall — the agent identifies tools from the photos, the fundi confirms and adds what's hidden. Every tool gets an access tier, because "can you use a circular saw" has three true answers:

{
  "business": {"name": "Yusuf O.", "cluster": "Gikomba", "years": 6,
               "workers": 2, "output_pcs_month": 8,
               "products": ["stools", "tables", "bed frames"]},
  "tools": [
    {"name": "hand saw",     "access": "owned", "condition": "good"},
    {"name": "No.4 plane",   "access": "owned", "condition": "blade worn"},
    {"name": "circular saw", "access": "borrowed_weekly", "owner": "neighbor"},
    {"name": "router",       "access": "none"}
  ],
  "materials": ["cypress", "mahogany offcuts", "MDF sometimes"],
  "rent_out_willing": true,          // asked at signup — feeds tool marketplace
  "goals": ["stop comebacks", "+KSh 500 per piece"]
}

The memory: a skill file, not a surveillance file

After each session the agent updates a per-user memory — the same pattern as an agent's project memory file, but about a person's craft. Three hard rules keep it an asset instead of an insult:

• Evidence-based: every skill observation cites the assessments it came from ("tenon gaps in 3 of last 4 pieces: #12, #14, #15"). No vibes.
• User-visible and editable: the fundi can read exactly what the app believes about their skills, and contest it. Memory they can't see would poison trust in a community where the app spreads by word of mouth.
• Framed as trajectory: the file stores direction, not labels — "joint fit: improving, last gap 2mm vs 5mm in June," never "bad at joints."

{
  "skills": {
    "sawing_straight":  {"level": 2, "trend": "up",   "evidence": ["a12","a15"]},
    "joint_fit":        {"level": 2, "trend": "up",   "recurring": "tenon undersize",
                         "active_drill": "knife-line + gauge, assigned 2026-08-17"},
    "finishing":        {"level": 3, "trend": "flat", "evidence": ["a09","a14"]}
  },
  "coaching_notes": "Responds well to cost-framed advice. Prefers Swahili voice."
}

This is what makes coaching compound: the agent opens a new project already knowing the weak spot ("before you cut the tenons — remember the knife-line"), which is exactly what a good senior does.

Key questions we had to answer

The product: basic scope

The interactive mockup walks Yusuf's first week: onboarding, diagnosing a stool he built yesterday, fixing it the same afternoon, and watching the memory kick in.

Extended: the marketplace layer

Each extended feature formalizes an exchange that already happens informally in a cluster — that's why we believe they can work. All of them ride on data the basic app already collects.

Architecture & build plan

What's shared, what's new

• Shared with Kagua (build once): capture client, compression/offline queue, assessment engine + protocol files, structured defect schema, report rendering, auth, storage.
• New for Fundi Bora: profile store + tool ontology, per-user memory files (agent-written, user-editable), coaching content layer (drills, technique cards — curated with master fundis, served by the agent), diagnosis prompt layer, marketplace tables (extended).
• Memory implementation: structured JSON + prose notes per user, injected into every session; agent proposes updates post-session, applied after a lightweight rules pass (no negative labels, evidence links required). Full session transcripts are not retained long-term — the distilled file is the memory.

Phased build (starts after Kagua P1 proves the engine)

Assumptions log

Open questions & next decisions

1. Sequencing: we've assumed Kagua ships first (it proves the engine and creates the demand signal). The reverse order — coach producers first so there's certified supply before buyers arrive — is defensible. Decide before P1.
2. Coaching content sourcing: which 2–3 master fundis co-author the drill library, and what do we pay them? This is the app's soul; it can't be an afterthought.
3. Worker vs. owner accounts: Yusuf's two casual workers — do they get their own skill files (feeds F-11 matching) or does v1 stay owner-only? Leaning owner-only, but F-11 eventually needs worker identity.
4. NGO/SACCO partnerships: tool-financing partners (SACCOs already lend for equipment) could turn tool recommendations into financed purchases — revenue share worth exploring.