How It Works

Overview

DevKeel turns your AI coding tool into a product coach. It coaches you through decisions, helps you frame work as testable bets, enforces quality gates, and validates whether what you built actually worked — all powered by persistent memory that compounds across sessions.

The core loop:

get_status → create_bet → build with context → review gates → check_signal → resolve_bet

Every resolved bet — whether it paid off or not — produces learnings that make the next bet smarter. This is the outcome validation loop that no other tool provides.

Projects

When you first connect your AI agent to DevKeel, it scans your codebase and creates a project automatically. The agent discovers your tech stack, file structure, test coverage, and CI configuration.

After discovery, you set project goals and context. The project then goes through an onboarding flow before becoming active.

new → awaiting_goals → onboarding → active

Context Repository

The context repository is a persistent knowledge base that stores decisions, conventions, requirements, learnings, and insights. Your agent can store and query context across sessions, so project knowledge accumulates over time.

Types of context: decision, convention, requirement, learning, insight, project_overview, architecture, contribution_guide, domain_knowledge, rejected_approach. Each entry includes content, rationale, and tags for searchability.

Coaching & Intelligence

When you call get_status or get_bet_status, your agent receives a coaching prompt with full context: your project knowledge, active work, recent signals, past learnings, and goals. This turns your LLM into a coach that remembers everything.

Intelligence Processing

DevKeel can process strategic intelligence — advisor call transcripts, articles, user interviews, competitive research, personal reflections — and extract structured insights linked to your active work.

1

Start with process_intelligence — provide the source type and content.

2

Your agent extracts insights, surfaces conflicts with current direction, and identifies action items.

3

Call complete_intelligence to store everything — insights become context entries, action items get tracked.

Use list_intelligence to browse past digests and list_action_items to track follow-ups. Intelligence insights surface automatically in future sessions when they're relevant.

Quality & Review Gates

After completing tasks, DevKeel runs review gates that check your work across multiple dimensions: code quality, test coverage, security, and product correctness.

Review gates are implemented as skills — structured instructions your agent follows to evaluate the work. Available reviews include:

Code Review

Test quality, hidden complexity, over-engineering.

QA Review

Happy path, edge cases, error states, regression.

Security Review

Auth, injection, data exposure.

Product Correctness

Does what was built match what was intended?

Use list_skills to see available review skills and get_skill to retrieve specific instructions. After running a review, submit results with submit_review. You shouldn't have to remember to run the linter or check for security issues — the review gates are part of the workflow, not an afterthought.

Bets & Signals

A bet is a testable belief about what will move your product forward. Each bet has signals — observable indicators that tell you whether the bet is paying off.

Before (idea)

"Let's add a search bar to the dashboard"

After (bet)

"We're betting that adding search will reduce time-to-action by 40%. Signal: average clicks to target, checked weekly for 2 weeks."

Bets move through a lifecycle as you track signals:

active → tracking → resolved / pivoted

Signals are what you observe: pricing page visits, user feedback scores, conversion rates. Use add_signal to define them and check_signal to record observations over time.

When signals tell a clear story, resolve_bet captures the outcome and learnings. If the data suggests a different direction, pivot_bet adjusts the bet while preserving what you've learned.

Learn and Pivot

The real value is in what happens after you check signals. Every bet ends with learnings that feed future bets.

Signal Checking

Signals come from different sources, depending on what you're tracking:

Application Analytics

For user behavior signals — conversion rates, feature adoption, engagement, retention.

Pull data from PostHog, Amplitude, Mixpanel, or your database. Record observations with check_signal.

Signal: "Free-to-paid conversion rate"

Observation: 8.2% this week, up from 5.1% baseline. Trend: positive.

Database Queries

For signals you can derive from existing data — counts, averages, rates.

Run a query before (baseline) and after, then record the comparison as a signal check.

Signal: "API response time at p95"

Observation: 180ms, down from 320ms. Target met.

Manual / Qualitative

For signals that can't be automated — user feedback, support tickets, usability observations.

Record findings as signal checks with your interpretation.

Signal: "User satisfaction after onboarding"

Observation: 4.3/5 avg from 25 respondents. Above 4.0 threshold.

Key principle: Define signals BEFORE you build. Your coach will remind you to check signals regularly and will use past learnings to suggest what to watch for.

Resolving Bets

When signals tell a clear story, resolve the bet and capture learnings:

Use resolve_bet to record the outcome and what you learned
Use pivot_bet if signals suggest a different direction
Learnings are stored in DevKeel's memory and inform future coaching

Every resolved bet — whether it paid off or not — makes your next bet smarter. Your coach remembers everything.

Deliverables & Tasks

When a bet requires building something, it breaks down into deliverables (scoped units of work), which break down into tasks (LLM-optimized execution units).

Bet → Deliverables → Tasks → Review

Each task gets a task brief with full context. After completing each task, a review gate checks code quality, tests, and security. When all tasks complete, the deliverable auto-completes.

Unplanned Work

Not all work fits neatly into a bet — and that's fine. DevKeel lets you create unplanned deliverables outside of any bet. These are logged against your project so nothing disappears between sessions.

Your coach helps classify work as it happens: Does this relate to an active bet? Is it a small deviation that should be linked? Or is it a completely different direction that might warrant a new bet? If unplanned work starts to outnumber planned work, the coach will gently surface this as a signal worth reflecting on.

Unplanned deliverables can be linked to a bet later using link_deliverable_to_bet once you recognize where they belong. Not every bet needs code either — some bets are purely about observing signals from existing features.

Common Situations

What if my bet doesn't pay off?

That's a win. You learned something quickly instead of investing months in the wrong direction. Resolve the bet with learnings, and your coach will use those learnings to suggest better bets next time.

Can I have multiple active bets?

Yes. You can track several bets in parallel, each with their own signals. Use triage to prioritize which bets need attention. The dashboard helps you track everything.

When should I pivot a bet?

When signals suggest a different direction than expected but the underlying goal is still valid. Use pivot_bet to adjust the bet while preserving your learnings and signal history.

Do I need to use bets right away?

Bets emerge naturally as you work. Your agent suggests framing work as a bet when it makes sense. You can start with coaching and memory — but the real payoff comes when you close the loop: bet, build, check, learn.

What if I need to build something outside a bet?

Go ahead. Create a deliverable without a bet and it gets logged as unplanned work against your project. Your coach will help you decide if it should be linked to an existing bet or if it signals a new direction worth betting on. Nothing is lost.

Can I use DevKeel with a new/empty project?

Yes. The agent handles greenfield projects by noting that the codebase is empty and helping you define goals from scratch. Your first bets might be about validating the market before writing any code.