See It in Action
Annotated examples from real sessions. Each one shows a different phase of working with DevKeel — from first connection to measuring what you shipped.
You've read about coaching, bets, and memory. Now see them working together in practice.
Jump to a scenario:
Onboarding a New Project
You've just connected DevKeel. Your agent doesn't know anything about your project yet. You say two words — and it figures out the rest.
# You say:
"Get my status"
# Your agent scans the codebase and reports back:
"I've discovered your project. Here's what I found:
Tech stack: Rails 8.1, PostgreSQL, Hotwire, Tailwind
Test framework: RSpec with FactoryBot
CI: GitHub Actions (test, lint, security scan)
42 models, 180+ tests, 87% coverage
What are the main goals for this project?"
# You set your goals:
"Launch the beta in 4 weeks. Get 10 paying customers by end of Q2."
What just happened
Your agent read your codebase — file structure, dependencies, tests, CI config — and built a profile of your project. Your goals are now stored permanently. Every future session starts with this context, not from zero.
Teaching Your Agent What Matters
Your agent knows the tech stack. Now teach it the things that aren't in the code — the decisions, conventions, and lessons your team has accumulated.
# You share decisions:
"We chose Stripe over Paddle because we need marketplace payouts."
"We tried a microservices architecture early on. It was overkill for our team size. Went back to a monolith and it's been better."
# Conventions:
"All API endpoints return JSON:API format. Controllers stay thin — business logic goes in service objects."
# Domain knowledge:
"Our users are property managers. A 'unit' is an apartment, not a code module. 'Turnover' means a tenant moving out, not employee churn."
# Your agent stores all of it:
"Got it. I've stored 4 decisions, 2 conventions, and 3 domain terms. I'll carry these into every future session."
What just happened
Your agent now has institutional knowledge. The Stripe decision means it won't suggest Paddle. The rejected microservices approach means it won't propose splitting the monolith. The domain terms mean it won't confuse your business language with programming jargon. This all surfaces automatically in future sessions — you never repeat it.
Creating Your First Bet
You have an idea for what to build next. Instead of jumping straight into code, your agent helps you frame it as a testable belief — so you'll know whether it actually worked.
# You share your idea:
"I think adding a self-serve onboarding flow will reduce support tickets. Right now every new customer needs a walkthrough call."
# Your agent helps you shape it into a bet:
"Let's frame that as a testable belief:
Title: Self-serve onboarding reduces support load
Belief: We believe that a guided onboarding flow will reduce new-customer support tickets by 40%, because most questions are about initial setup — not the product itself.
Timeframe: 3 weeks
Signal: Support tickets from accounts less than 7 days old drop by 40%
Should I create this bet?"
# You refine and confirm:
"Yes, but make it 2 weeks. And add a second signal: 80% of new users complete onboarding without contacting support."
What just happened
Instead of a vague task like "build onboarding," you now have a testable hypothesis with a timeframe and clear success criteria. In two weeks, you'll check those signals and know — with evidence — whether this bet paid off. If it didn't, you'll capture what you learned and adjust.
Building with Memory
A week has passed. You open a new session to continue working on the onboarding feature. Your agent picks up exactly where you left off.
# You say:
"Let's keep working on the onboarding flow. Where were we?"
# Your agent already knows:
"You're working on the self-serve onboarding bet (12 days left). Here's where things stand:
Completed: Account setup wizard, welcome email sequence
In progress: Interactive product tour (3 of 5 steps built)
Remaining: Progress tracking dashboard, completion trigger for support handoff
Last session you decided to use Shepherd.js for the tour instead of building custom — should I continue with step 4?"
What just happened
No re-explaining. No pasting context. Your agent knows the bet, the timeline, what's done, what's in progress, and even the library decision from last session. You went from "where were we?" to productive work in seconds.
Running Reviews
You've finished implementing the product tour. When your agent marks the task complete, a review gate kicks in automatically — checking the work against your project's standards.
# Your agent completes the task and triggers the review gate:
"Task complete. Running reviews against 6 changed files..."
# Review results come back:
"Review report:
Code review: PASS — follows service object pattern per your conventions
Security: WARNING — tour step URLs aren't validated against allowed paths (medium)
Tests: PASS — 12 new specs, all passing, covers happy path and edge cases
Product: PASS — implementation matches the onboarding bet's acceptance criteria
I'll fix the URL validation issue now."
What just happened
Your agent reviewed its own work across multiple dimensions — code quality, security, test coverage, and product correctness — without you asking. The security issue was caught and fixed before it shipped. These reviews run on every task completion, using standards tailored to your project.
Processing a Call with a User
You just got off a call with an early user. They shared feedback about the onboarding flow — some of it validates your bet, some challenges your assumptions. Your agent helps you extract and store what matters.
# You share the context:
"I just had a call with an early user. They said the onboarding wizard is great for setup, but the product tour feels too long. They skipped steps 3 and 4. They also mentioned that what they really needed was a way to import existing data — that was their biggest friction point, not learning the UI."
# Your agent extracts and stores insights:
"I've captured the following from this call:
Insight: Product tour too long — users skip middle steps
Insight: Data import is the real onboarding friction — bigger than UI learning curve
Evidence for onboarding bet: Setup wizard validated, tour needs shortening
Action item: Research CSV/API import options for existing customer data
This changes your bet's trajectory. The tour signal may not be the right thing to measure — data import success might matter more. Want to adjust the bet?"
What just happened
A conversation that would normally live in your notes (or nowhere) is now structured project knowledge. The insights are stored, linked to the active bet, and will surface in future sessions. Your agent even flagged that user feedback challenges your original hypothesis — prompting you to adjust before you invest more time in the wrong direction.
Checking Signals and Resolving a Bet
Two weeks are up. Time to check whether the onboarding bet paid off — and capture what you learned either way.
# You check the signals:
"How did the onboarding bet do?"
# Your agent reviews the evidence:
"Here's where the signals landed:
Signal 1: Support tickets from new accounts dropped 25% (target was 40%) — partially met
Signal 2: 55% of users completed onboarding without support (target was 80%) — not met
Key evidence: User feedback shows data import — not the tour — is the main friction point
The onboarding wizard helped, but the bet's original hypothesis was partially wrong. Support tickets dropped because setup got easier, not because users stopped needing help. The real bottleneck is data migration."
# You resolve the bet:
"Resolve it. Signal partially met. The learning is that onboarding friction is about data, not UI. Let's create a new bet focused on data import."
# Your agent captures learnings and pivots:
"Resolved. Learnings stored:
Validated: Self-serve setup wizard reduces basic support questions
Invalidated: Product tours don't drive completion — users skip them
Unexpected: Data import is the real onboarding bottleneck
New bet created: 'Data import flow reduces onboarding support load.' This carries forward the learnings from the previous bet."
What just happened
You didn't just ship a feature and move on. You checked whether it worked, captured specific learnings, and pivoted based on evidence. The original bet wasn't a failure — it produced validated knowledge that directly shaped what you're building next. These learnings are permanent. Future bets and decisions will reference them automatically.
The Thread That Connects Them
These aren't isolated features. Each scenario builds on the last. Your agent's memory from onboarding informs how it coaches during building. Reviews reference your conventions. User feedback reshapes your bets. Learnings from resolved bets influence what you build next.
The longer you use DevKeel, the more context your agent accumulates — and the more useful every session becomes.