Main story · speaker script
Untimed · SLIDE 1
The portal is open.
DO Let the room settle. Use fullscreen if presenting. Choose Begin when you are ready.
THEN We had a plan. The AI had other plans.
Leave this screen on while people join. The supplied portal animation loops silently. Pause motion if preferred; reduced-motion settings show the still image by default. This holding screen is outside the 50-minute talk. When everyone is ready, choose Begin or press the right arrow: the original opening starts on slide 2. The illustration sets the atmosphere; it is not evidence of product behavior.
00:00–01:00 · SLIDE 2
We had a plan. The AI had other plans.
SAY Who has corrected an AI on something you agreed three hours ago?
DO Pause for hands. Let the dashboard-to-platform joke land. Introduce yourself in one sentence.
THEN First, the whole system. Then we open it one part at a time.
I am Johannes, and Lintel is my independent open-source engineering project. You write a detailed plan. Hours later the agent is doing impressive work, but the scope has moved. Or it stops, and you have to reconstruct the next step. Then you repeat the same architecture and quality instructions in another repository. I became a rather expensive copy-and-paste loop.
A lintel is the beam over an opening that carries the structure above it. That is the metaphor: useful structure supports the work. Today we follow intent through implementation and review, then see what survives the next session. The conversation on screen is illustrative, not a recorded experiment. We will separate implemented mechanisms, saved demonstrations and things we still need to measure.
01:00–02:30 · SLIDE 3
Here’s the whole system.
SAY Your coding agent executes. Lintel supplies a shared way to work.
DO Trace client → method → project records → next task. Mention the team pack and platform boundary; save detailed paths for later.
THEN Six simple words make this map easier to read.
Lintel is a kit of repository instructions, workflows and local helpers inside the coding client you already use. There is no hosted Lintel service or background daemon. The host owns the model, tools, permissions and execution.
The company-neutral spine carries the method. A separate pack supplies the standards, knowledge, roles and language your team owns. Skills tell the agent how to perform a job; roles give delegated workers a focused assignment. Agents and helpers maintain plans, decisions, lessons and a handoff. Later work reads relevant records.
The arrows describe a workflow, not a promise that every action is automatically intercepted. Hooks support selected events where registered. Permissions and CI remain platform controls. Current source is version 0.12.0, still a public beta. A file being present does not prove a host ran it.
02:30–03:30 · SLIDE 4
Six parts. One working system.
SAY Scaffolding is where it lives. The method says how to work. Compounding brings useful learning back.
DO Use one short sentence per part. Explain that an agent role is a job description and a hook reacts to an event.
THEN Bring the same method to four supported client families.
Scaffolding gives the project places for instructions, plans, decisions, lessons and handoffs. The method defines the workflow and when clarification or review is needed. Skills are reusable recipes for jobs such as architecture, technical review or testing. Agent roles provide focused expertise; separate execution depends on host support. Hooks are registered event checks, not an intelligent observer of everything. Compounding means a reviewed lesson or decision is retrieved and applied to later relevant work. A team pack changes the standards and context across these parts. Compounding needs retrieval and verification; accumulating more files alone does not create value.
03:30–04:30 · SLIDE 5
Four client families. One shared method.
SAY Copilot, Claude, Codex and Cursor. Shared method, surface-specific execution.
DO Name four families, then CLI / desktop / IDE / cloud. Explain the evidence ladder once.
THEN That also makes it easier to say what belongs elsewhere.
Lintel deliberately supports four families: GitHub Copilot, Claude, Codex and Cursor. The earlier much larger registry was narrowed to focus maintenance on the clients the team uses. There are thirteen named surfaces plus the manual other route. Twelve records have native-format discovery; Codex cloud and other use explicit file handoff.
A CLI record is not proof of desktop, IDE or cloud parity. The registry separates vendor documentation, delivered files and observed execution. Most execution records remain not_run. Partial Copilot App observations do not certify that entire family.
The repo kit keeps one shared source bundle and fifteen starter workflow wrappers, including MARS. It installs no hooks. Copilot has its own hooks, but Lintel has not translated its Claude Code hook bundle to that API. Pilot the exact surface, version and policy you intend to use.
04:30–05:00 · SLIDE 6
No single harness. No magic ring.
SAY There is no single harness to rule them all.
DO Keep this to thirty seconds. Describe complementary jobs, not a feature comparison.
THEN The problem I started with was simpler: what can the next session actually see?
MDASH and AGT are useful reference points from our engineering conversations. They address their own jobs and do not need replacing for Lintel to be useful. Lintel focuses here on the workflow around coding work: scope, context, execution, review and continuity. Another tool's report can be input without implying a native connector.
MARS, which we will see later, is now a Lintel review workflow. Keep it distinct from swarming: multiple perspectives on one subject versus workers implementing different packages.
05:00–06:30 · SLIDE 7
A fresh session. A new window.
SAY A new conversation gets a new working window. It does not inherit every decision.
DO Click Three hours later. Define agent, context and session; keep the invented counts illustrative.
THEN Separate the intent, the method and the reason—and give them somewhere durable to live.
An agent is a model with tools that can read files, edit and run commands under host permissions. Context is what the model can see for this turn: instructions, files, tool results and conversation. A fresh session needs relevant context loaded again.
Click Three hours later. This is an illustration with invented counts. Hosts manage long conversations differently through selection, compaction and truncation. Even when a decision exists in the transcript, we should not depend on it being used correctly later.
Do not put the whole repository into every prompt. Keep current intent, relevant decisions, the next task and its acceptance available. Retain sources and select deliberately. A memory file that is never read is a very organised way of forgetting.
06:30–07:30 · SLIDE 8
What. How. Why. Then make it compound.
SAY What are we building, how do we verify it, and why this approach?
DO Point once to each word; explain compounding with the return arrow.
THEN Here is the method that turns those questions into an executable path.
Here is the method in three words. What defines the outcome and scope. How makes execution and verification explicit. Why preserves the reasons behind choices so later sessions can reuse them. Next, follow these responsibilities through the cycle. WHAT is the intended result and its boundaries: who is this for, what changes, and what does done mean? HOW is the work: a plan at an actionable level, a repeatable workflow, and specific review and verification steps. WHY is the decision context: constraints, rejected alternatives and the reason we chose this approach. Then compound: capture a correction, retain the decision, and retrieve it when the next task matches. The workflow asks for these artifacts. The artifact itself is not a guarantee of quality. Evidence and review have to make the contract real.
07:30–09:30 · SLIDE 9
Agree the work. Then build the work.
SAY The expensive mistake is correct code built against the wrong premise.
DO Trace understand → agree → build → review → capture. Click PLAN and REVIEW; do not recite nine definitions.
THEN No, a typo should not need the whole ceremony.
The full cycle is SENSE, SCOPE, DEFINE, DISCOVER, PLAN, BUILD, REVIEW, SHIP and CAPTURE. Think in three chunks: understand and agree; implement and verify; leave a useful trail.
PLAN aligns the original specification, task map and handoff. You authorize the plan before substantial implementation. BUILD executes coherent packages with short verifiable leaves. REVIEW checks requirements, quality and active-pack compliance. SHIP follows the authorized delivery path. CAPTURE updates useful lessons, decisions and working state; not every cycle needs a new ADR.
These instructions are backed by specific helpers, not a universal scheduler. Content-bound checks validate selected evidence; actual tools and release remain under platform control. Swarming changes how approved packages execute, not the phases or requirements.
09:30–10:30 · SLIDE 10
Nine steps for a typo?
SAY Use the shortest route that preserves the necessary checks.
DO Show hotfix and research. Use the full-cycle row to contrast a feature. Do not improvise routing predictions.
THEN Once the route is chosen, stop rewriting the same quality instructions.
A known fix can use SENSE, BUILD, REVIEW and SHIP. Research stops after SENSE, DEFINE and DISCOVER. A feature can use the full cycle, sized to risk. Explicit phase ranges keep their prerequisites.
These illustrative examples came from the recorded keyword-routing experiment. A keyword match is advice, not understanding. An explicit mode wins; resolve ambiguity before following a suggestion. The short route preserves review and authority. You should feel saved repetition, not an obligation to invoke ninety-six things.
10:30–11:30 · SLIDE 11
Your fifth dashboard should remember the first.
SAY The fifth dashboard should reuse the questions, not inherit the first customer’s answers.
DO Click Package the pattern once. Mention empty states and export consistency.
THEN A reusable method still has to produce the right level of plan.
Imagine building dashboards across five repos. Each time you ask for sensible empty states, meaningful time axes, accessible charts, correct filtering and exports that match the screen. Those are recurring review questions. A reusable skill can carry them once. It should not blindly carry the previous customer's requirements or architecture. The reusable part is the decision procedure: what to inspect, what to ask, what evidence to produce and when to stop. Click Package the pattern. The invariant checks move into the skill; the new repo's data, audience and constraints still enter every time. This is deliberate reuse, not copy-paste architecture.
11:30–13:30 · SLIDE 12
Small steps. A coherent piece of work.
SAY Small enough to verify. Coherent enough to deliver.
DO Walk T01–T03 as one package. Explain the defect when CSV and screen filters differ.
THEN Then ask a stronger question than “does this look good?”
The hybrid rule keeps short two-to-five-minute leaves but executes and reviews a coherent work package. A leaf needs an action, target and acceptance check. The package owns a useful outcome: consistent filtering across dashboard and CSV.
T01 defines active. T02 shares one dataset contract. T03 verifies the export. These are separate checks, not separate visions. One implementer owns the bounded package, followed by spec and quality review covering every leaf. A failed leaf keeps the package open.
Dependencies and ownership determine concurrency. More checkboxes do not make a better plan. A fresh worker should know what to do; a reviewer should be able to establish completion. Preserve original finding IDs when turning a report into repair packages.
13:30–16:00 · SLIDE 13
“Looks good” is not a review.
SAY What was checked, what was found, and what remains unknown?
DO Trace the cancellation question through evidence to decision. Distinguish executed from traced evidence.
THEN Those questions matter more when the system knows this project’s actual standards.
Lintel now has one Review Method. A single reviewer and each MARS slot receive the same packet body. Standing questions are selected for the subject and relevant surfaces: contracts, boundaries, failure paths, trust, consumers and more. The coordinator confirms tags; keyword guesses are not the final risk assessment.
Can cancellation restore stock twice? A useful finding names the input, actual result and smallest fix. Applicable questions need explicit coverage. Silence is not a pass. A checked row needs evidence; unverified requirements and missing coverage remain incomplete.
Four evidence levels separate executed, traced, pattern and hypothesis. Severity follows consequence, not confidence or taste. P1 fails, P2 requests changes and incomplete evidence stays incomplete.
The record binds to selected content, acceptance and profile. Changed inputs invalidate old clearance; a later relevant rejection overrides an earlier pass. Helpers validate the record and its binding. They cannot guarantee model understanding or turn a self-claimed actor name into proven independence.
16:00–18:00 · SLIDE 14
A profile should change the work.
SAY Enterprise is not a theme color. The requirements must change.
DO Toggle Lab → Customer pilot. Read the changed evidence field.
THEN Separate configuration from the knowledge that travels with the repository.
Remember the pack from the kit screen: the team’s standards. This switches between two of them, a lab and a customer pilot. Switch between Lab and Customer pilot. This is a separate, deterministic demo: no model runs here, and it is not part of the paired agent builds. The actual Lintel pack resolver supplies values from two synthetic manifests. A presentation consumer turns them into the displayed contract. Notice the evidence requirement changes from a smoke test to a tenant negative test; identity and network design requirements change too. The demo_policy fields are custom presentation fields. No identity or network infrastructure is provisioned, and hard mode is a configuration value, not proof of enforcement. The value hypothesis is concrete: a profile should change decisions, questions and acceptance evidence.
This saved mechanism proof predates the Universal integration. It retains its original provenance. Current Universal adds content-bound profile identity, shared lifecycle recovery and structured evidence; this older run does not verify those additions.
18:00–19:30 · SLIDE 15
Your setup. Your project’s memory.
SAY Your setup stays with you. The project’s reviewed knowledge travels with the project.
DO Trace left → right, then the Git arrow. Point to the dashed runtime box last.
THEN These files matter only when the workflow writes and reads them.
Remember the window: files are what survive a session. This is where Lintel puts them. Point to the left first: machine-global means reusable across projects on this computer. The ~/.lintel/ home contains your profile and installed packs, as well as operator-wide records. Your coding client owns its own settings, tools and permissions; ~/.claude/ is a Claude-specific home, not a universal home for every app. Now point right: the project repository keeps reviewed memory, decisions, plans and handoffs under its declared paths. In the standard Lintel layout that is .claude/memory/, .claude/decisions/ and .claude/plans/. Commit the appropriate reviewed knowledge so Git can carry it to the next person or session. The dashed area is .claude/runtime/: temporary execution state is ignored and does not travel in a normal clone. The .claude folder name does not require Claude Code. Client adapters (the files that teach one coding tool where to find all this; the technical module has the full path matrix) can add their own files; the Copilot route of the Universal repository kit uses .github/copilot-instructions.md, .github/skills/, .github/agents/ and .github/lintel/. Those details are in the field guide. Your global profile and installed packs do not automatically appear on a colleague’s machine through Git. The active pack must be available and configured there. The point is to separate reusable operator context, portable project knowledge and disposable run state.
The shared source bundle remains .github/lintel/ for compatibility. Other selected surfaces get their own discovery roots pointing into it. A repo can require a specific pack in .claude/profile-requirements.json; profile.yaml carries role/mode preferences, not pack selection. Bound profile drift requires explicit reconciliation. See the technical module for exact paths.
The portable repository kit defaults its configuration home to .claude/runtime/lintel-home, while bare installation defaults to ~/.lintel. An explicit LINTEL_HOME overrides the default. The diagram distinguishes these two routes; a global home is not required.
19:30–21:00 · SLIDE 16
The work leaves a way back.
SAY The agent should not need your memory to find its next task.
DO Click through the three example steps: clarification, saved decision, fresh session. Explain who asks and who writes. Keep the registered-hook lane separate.
THEN Inspect a saved cold-start example rather than trusting the arrows.
The method requires the agent to clarify material ambiguity, record consequential decisions, keep the plan current and capture evidence. Skills turn those requirements into concrete instructions; agents and local helpers perform the writes. They maintain the existing scaffolding instead of inventing a new memory store. This example begins with an export task and an unresolved date boundary. The workflow surfaces the ambiguity and the agent asks whether dates use UTC or local time. The human answers UTC. The agent records that decision, updates the task and identifies the boundary test as the next action. A compatible SessionStart hook can surface a digest, and a prompt-position hook can reassert the current step. A fresh agent still reads and checks the authoritative files before continuing. Hooks run only on exposed and registered events. A hook may warn, supply context or block selected operations, according to its actual contract; it does not itself understand every uncertainty or guarantee that a question is asked. Stop warnings do not force auto-continuation. Keep reviewed decisions and handoffs with Git; keep temporary counters and runtime ledgers ignored. The quality comes from both writing and reading the trail.
21:00–23:00 · SLIDE 17
Delete the chat. Keep the plot.
SAY We lose the runtime, not the plot.
DO Trace the four committed pointers to T002. The saved helper checks the map.
THEN Continuity preserves the next action. Learning should preserve a correction.
This is the window idea, applied: assume the session is gone — what is left on disk? We do not delete anything in your real repo. The prepared proof creates a local clone of a synthetic fixture without the ignored runtime ledger. The committed specification, plan, tasks and handoff survive. Show the four pointers and the next action T002. The helper validates the map and file boundaries; the explicit handoff supplies the next task. It is not the helper reasoning about priorities. Missing files and a path escaping the repo are rejected in the saved run. A fresh agent still needs to read and reason about those artifacts, but it no longer has to recover the project from chat archaeology. The four on-screen labels stand for the exact committed paths shown in the offline field guide and helper proof explorer.
This saved mechanism proof predates the Universal integration. It retains its original provenance. Current Universal adds content-bound profile identity, shared lifecycle recovery and structured evidence; this older run does not verify those additions.
23:00–25:30 · SLIDE 18
A lesson that never returns is just a diary entry.
SAY Put the bug back. Does the test notice?
DO Click Before → Fixed → Reintroduce bug. Read the red result aloud.
THEN Different knowledge needs different durable forms.
Show Before: lookup by document ID allows another tenant's document. Switch to Fixed: the same three tests now include the tenant condition. Then select Reintroduce bug: deliberately run the vulnerable version again and watch the cross-tenant check fail. That is the important negative control. The prepared lesson is retrieved through the real keyword-scoped memory helper; an obsolete lesson and an unrelated lesson are excluded. This is not model training and not proof of production authentication. It is an example of turning a specific correction into both reusable context and executable protection. Read the red result aloud for remote participants.
This saved mechanism proof predates the Universal integration. It retains its original provenance. Current Universal adds content-bound profile identity, shared lifecycle recovery and structured evidence; this older run does not verify those additions.
25:30–26:30 · SLIDE 19
Correct once. Make the correction travel.
SAY A correction becomes useful when the next relevant task can find it.
DO Explain the different jobs of a lesson, ADR, skill and test.
THEN Once work and evidence are explicit, we can discuss more than one worker.
A lesson remembers a failure mode and when to look for it. An ADR remembers a decision and its rationale. A skill remembers the reusable method. A test remembers an observable boundary. They work together, but they are not interchangeable. Do not turn every preference into a permanent constitutional rule. Record scope, source and review status; retire what becomes wrong. Compounding context means the next relevant task starts with better material. It does not mean an ever-growing prompt, and it does not promise an exponential learning curve.
26:30–29:00 · SLIDE 20
Parallel work. One accountable plan.
SAY Swarming divides implementation. It does not divide accountability.
DO Trace task map → independent writer lanes → lane reviews → integrated review. Use report remediation as the example.
THEN MARS adds different perspectives on the same subject.
Triage a bug list or MDASH report into approved packages, preserving the original findings and acceptance. Parallelize only packages whose dependencies and ownership permit it. Swarming is opt-in over PLAN, BUILD and REVIEW.
One coordinator owns shared task state, generated outputs, commits and integration. Workers write declared paths and report. Separate reviewers examine the lanes. Concurrent writers require attributable worktrees, isolated patches or equivalent host-enforced scope. A shared-folder promise is insufficient.
Passing lane reviews are inputs, not final acceptance. Reconcile the branch and review the integrated result. Without isolation, replay the same briefs serially. Without independent review, keep that requirement open.
Recovery comes from artifacts and attributable changes, not a running-status label. Agree delivery packages, PR authority and stop conditions before dispatch. Optimize accepted changes rather than busy-agent counts.
29:00–31:00 · SLIDE 21
Same question. More than one perspective.
SAY Swarm builds different packages. MARS reviews one subject from different models.
DO Trace one frozen packet into separate contexts and evidence-based synthesis. Point to the incomplete slot.
THEN Now the personal swarming moments should make more sense.
MARS sends the same Review Method body to separate reviewer contexts. Each first pass is blind to the others. The coordinator deduplicates and adjudicates by evidence, with a challenge round when contested and authorized. Agreement is not a majority-vote permission to ship.
The host must prove separate contexts, per-child model selection, allowed delegation and observable identities for at least two distinct models. An offer, silence or auto mode is not consent. The helper resolves live models and validates state; it never dispatches, authorizes or closes sessions itself. Actual host tools do that work.
In the recorded synthetic RM9 pilot, three valid reports aligned on one contract-breaking defect. A fourth had a bad header and hash and was refused. The panel remained partial and multi-model verification was false. This shows the refusal boundary, not ROI or model rankings.
Standalone MARS is advisory. REVIEW can use an adjudicated panel through its own content-bound stage decision and coverage rule. Panels have token and coordination overhead; use them when the cost of a missed issue justifies it.
31:00–31:30 · SLIDE 22
I stopped being the queue.
SAY Here is a day from before I had swarming in Lintel. Fifty-five contributions. Then I changed how I organised the work.
DO Point to 55. Click “Then I turned on swarming.” Let 711 land in silence for two beats. Point to the original screenshots, then trace the report-to-fix flow. Use “Replay reveal” if rehearsing.
THEN More throughput also gave me a very large reminder about delivery boundaries.
Before swarming, one busy day showed 55contributions. Afterwards, this day showed 711. [Reveal.] That changed the scale of work I could coordinate. These are two personal activity snapshots, not proof of quality or a measured speedup. More activity still has to become reviewed, useful changes. And that brings me to the next morning.
31:30–32:00 · SLIDE 23
We broke GitHub.*
SAY 740 commits. 760 files. One very unhappy browser tab.
DO Point to the unresponsive-tab message, pause for the joke, then move on. Do not open the enormous PR live.
THEN The comic version is an unhappy browser. The serious boundary is what has permission to happen.
I tried the new swarming and left it working overnight. I forgot to authorize pull requests along the way. The result: 740 commits, 760 files—and an unresponsive browser tab. So, obviously, we broke GitHub. [Pause.] My tab, to be precise. More throughput still needs small, reviewable deliveries.
This is my account of the incident. The supplied screenshot documents the visible PR counts and unresponsive tab, not a GitHub outage or a measured productivity gain. Agree PR authorization, bounded delivery packages and a stop condition before dispatch. A missing delivery decision is a reason to pause the affected work, not permission to keep expanding it.
32:00–33:00 · SLIDE 24
Markdown can tell you to lock it. It cannot be the lock.
SAY The instruction describes the lock. The platform has to provide it.
DO Point to both objects; name permissions and CI as examples.
THEN Finally, test whether the structure earns its overhead.
This matters when we talk to customers. The harness can structure the work, ask for evidence and invoke supported checks. Actual permissions, identity, network isolation, CI and deployment approvals must be configured and verified in the platform. A skill saying use least privilege does not grant or enforce least privilege. Likewise, universal method does not mean every host supports the same hooks or parallel agents. Keep this distinction crisp. It makes the rest of the story more credible and gives architects a clear boundary.
33:00–34:30 · SLIDE 25
Same kitchen. Three ways to build.
SAY The fair comparison must be allowed to disappoint us.
DO Show three arms and the frozen brief. State results are pending before describing expected value.
THEN Inspect the same behaviors in every real candidate.
Service House is a restaurant operations app: Menu, Orders, Inventory and Reports. Every arm receives the same prompt, brief, fixture, starter and acceptance. Thirty-two requirements are worth a hundred points. The prompt forbids follow-up questions, so Lintel cannot receive extra requirements the baseline lacks.
Naked Copilot has no Lintel or delegation. Lintel serial uses packages and independent review. Swarming retains the same Lintel and delegate configuration but executes eligible packages concurrently. Naked versus Lintel changes workflow and model mix; an all-same-model series would isolate the workflow further.
Version 2 gives the controller server-readiness and submission ownership. No accepted controlled comparison exists. Builds happen beforehand; we inspect the artifacts together. This is the experiment contract, not a victory chart.
34:30–36:30 · SLIDE 26
A receipt beats a pretty screenshot.
SAY The app can look finished and still get dinner wrong.
DO Walk the three actions. Use the guide until actual accepted candidates exist. Never substitute the reference solution for an arm.
THEN A plan matters if its requirements survive into these checks.
Apply the same actions to every frozen candidate. Two soups, lemonade and KITCHEN10 should total 21.29. Cancellation restores reserved stock exactly once. Reload preserves orders and inventory without repeating checkout.
Trace K20 from the brief to its package, implementation and repeated-cancel check. Explain a difference through decisions and evidence. Do not prewrite a thin losing plan and a rich winning one.
With no accepted comparison, show the protocol and state the limitation. Reference and broken-control scores calibrate the grader; they are not agent results. The v2 controller owns the server and stop boundary. HTTP readiness, usable UI and passed acceptance remain different measurements.
36:30–38:00 · SLIDE 27
Four measures. Zero invented winners.
SAY Time, quality and cost are separate questions. Unknown is not zero.
DO Read the measures. Explain one confound and why failures stay in the result set.
THEN Return to the strongest reason for Lintel to exist.
Measure usable UI separately from first HTTP and submission. Grade frozen candidates against the same requirements. Retain failed runs, timeouts and exclusions. Cost includes coordinators, workers, reviewers and retries from actual receipts; missing billing stays unknown.
Run sequential arms, counterbalance order and repeat. Verify active implementation overlap for swarming: open sessions or parallel reviewers are insufficient. Report model, knowledge, tool and permission differences.
No completed accepted comparison is published. The protocol and exact input are available afterwards. Optimize time to an accepted useful change, not time until an agent says done.
38:00–39:00 · SLIDE 28
A smarter model still wasn’t in last week’s meeting.
SAY Even a smarter model was not in last Tuesday’s meeting.
DO Use the rejected-option example. Intelligence cannot replace unavailable project knowledge.
THEN That argues for a smaller useful core, not more instructions everywhere.
As models and native agent tools improve, generic advice to plan carefully or act like an expert becomes weaker differentiation. The strongest value hypothesis is project-specific knowledge: why we rejected an alternative, which requirement the team accepted, what must survive a handoff, and which check has caught a real mistake. The model cannot recover an unavailable decision by being more intelligent. Native tools already provide useful building blocks; Lintel must earn its place through the content, coordination and observed results. That is why this demonstration compares against a competent repo with ordinary project instructions and checks, rather than an artificially weak prompt-only baseline.
39:00–40:00 · SLIDE 29
96 skills. A smaller working set.
SAY The library got smaller. Each task should load only what it needs.
DO Name three consolidated methods; do not read the catalog.
THEN Make the first useful customer workflow easier to teach.
There are ninety-six canonical skills today, rather than the previous one-hundred-and-twenty-seven-entry presentation. Roughly eighty was an earlier direction, not a deletion target. Consolidation reduced overlapping entrypoints while retaining saved work, ownership and evidence contracts.
DEFINE owns intake. INSPECT unifies lenses. VERIFY checks by default; repairs need authority. PAUSE and RESUME preserve continuity. WEB-SESSION groups browser modes. MARS adds a distinct review use case. Specialist depth remains available with its real limitations.
The small default is intent, relevant context, next action and evidence. Add depth for a tenant boundary; do not impose the same process on a button label.
40:00–41:30 · SLIDE 30
Different roles. Shared context.
SAY The same context helps us in different parts of the customer journey.
DO Give one concrete benefit each for demo builder, architect and developer.
THEN Pick one recurring workflow and measure it.
For demo builders, the opportunity is more reproducible demos, a clear story about trade-offs and less time reconstructing context before a customer meeting. For architects, it is explicit constraints, traceable decisions and a cleaner architecture handoff. For customer developers, especially newcomers, it is a practical way to turn an intent into a verifiable slice without having to invent the review discipline each time. These are proposed benefits to test in a bounded pilot. We are not claiming a measured customer outcome from this presentation.
For developers new to agentic coding, teach a small verified slice and a reliable way to resume. This may accelerate vibe coding by reducing repeated specification, but it needs a pilot. A person-driven workflow in an existing coding app does not always need a new hosted application. Unattended services and scheduling still need appropriate hosted infrastructure. The smaller Lintel Core distribution remains planned.
41:30–43:30 · SLIDE 31
Don’t roll out a philosophy. Run a small experiment.
SAY One repeating workflow. Several comparable tasks. Then decide.
DO Point at the four measurements on screen. Keep “what would make us stop?” rhetorical — the discussion is next.
THEN Keep that recurring task in mind for the discussion.
Pick a repeating workflow, such as a customer demo dashboard or a prototype handoff. Agree what good looks like before running it. Track rework, missed requirements, handoff completeness and time spent maintaining the workflow. Use several comparable tasks, not only the most flattering run. Keep human review and the same underlying platform controls. Stop or simplify if the method costs more effort than the problems it prevents. A successful pilot gives us a reusable asset and evidence; an unsuccessful pilot gives us a useful boundary.
43:30–49:00 · SLIDE 32
What are you tired of explaining twice?
SAY What are you tired of explaining twice?
DO Take a remote participant first. Choose one task, one recurring failure and what should remember it.
THEN The method, sources and limitations are available after this session.
Give the room a few seconds to think, then take one answer from a remote participant first. Ask for a specific recurring task rather than general enthusiasm about agents. Which part should be a skill? Which decision belongs in an ADR? Which mistake deserves a regression test? What would make this too heavy? The goal is not to collect a huge roadmap in four minutes. Choose one candidate workflow and an observable failure that a pilot could try to prevent. If there is disagreement, use it: different contexts may need different harnesses.
49:00–49:30 · SLIDE 33
The talk ends. The toolkit stays.
SAY Four things to take forward. One available today; three links to follow.
DO Name the four deliverables. Explain Core as the small, explicit workflow shell for a customer case. Point attendees to the public site.
THEN Keep what supports the work. Make the useful part reusable.
You will get four things. Lintel is the full open-source harness. Pack number one adds the MS employee in CAIP context; its distribution link will follow. Lintel Core is the planned stripped-down shell for building a specific customer harness. The intention is explicit, on-demand use inside the customer’s existing coding desktop or CLI, including GitHub Copilot. It is useful when a person is driving a bounded workflow and a separate hosted agent or dedicated application would add unnecessary operational work. It does not replace hosted orchestration when you need unattended execution, shared services, durable infrastructure or platform controls.
Lintel Benchmark is the planned evaluation package; its link will follow too. The prepared A/B lab on this site is available now, but it is not a statistically established productivity benchmark. No private employee pack is included in this public site. The presentation, technical reference, notes and prepared browser demos can already be used here or downloaded as an offline kit.
49:30–50:00 · SLIDE 34
Keep the creativity. Stop paying twice.
SAY Keep the creativity. Stop paying twice.
DO Do not read the rows; give today’s example for each: the 09:12 agreement, the rejected option B, the tenant leak. Pause. End on time.
Close on the practical loop. Three rows, three things we keep paying for twice. The same explanation: write the plan and the handoff where the next session can read them. The same decision: record why, not only what. The same mistake: capture the lesson and give it a test. State the intent. Make the work inspectable. Keep the decisions alive. Retrieve the right lessons. Verify what matters. Lintel is my attempt to make that loop reusable across the tools I work in. It does not replace engineering judgment; it gives that judgment somewhere durable to live. Invite the team to inspect the actual prepared outputs and the comparison protocol in the package; the repository address is on screen. If we named a task in the discussion, try it on that one and tell me what it cost. End on time.