An AI-First Second Brain for Engineering Teams: My Talk at KLA

Sat, 26 Sep 2026 00:00:00 +0000

I had the opportunity to speak at KLA‘s Engineering Conference, an event attended by 800–1,000 engineers, about a problem that sits underneath much of our engineering work: remembering enough of the right context to make the next decision well.

KLA serves the semiconductor industry with process-control, inspection, and metrology technologies. That made it a fitting setting for a conversation about preserving context across complex engineering work.

My talk, “AI-First Second Brain for Engineering Teams,” explored how AI can help preserve that context without turning every conversation, incident, or provisional idea into permanent truth.

I had a 90-minute slot. The talk itself lasted 75 minutes, followed by more than 30 minutes of Q&A, taking the session beyond its allotted time. There was a lot of enthusiasm for the topic, and it was encouraging to see that interest continue into the discussion.

The message I wanted to leave with the audience was simple: AI can do much of the work of organizing and maintaining memory. People still need to decide what is safe to share, what deserves to be remembered, and when an old lesson applies to a new situation.

On stage at KLA’s NEOTERIX 2026 Engineering Conference in Chennai.

The work before the work

Think about a difficult engineering issue. The logs are in one place. Someone else has the physical observation. The reason for an old design choice is buried in a discussion. A workaround exists in the memory of an engineer who happens to be unavailable.

Before anyone can investigate properly, the team has to reconstruct the story.

I described this in the talk as engineering archaeology. We are searching for what happened, who understood it, which assumptions mattered, and whether the previous solution is still relevant. The information may exist, but it is not yet a usable starting point.

That reconstruction carries a memory tax. Engineers pay it when debugging an unfamiliar failure. Managers pay it when recovering an unowned commitment. Leaders pay it when trying to understand whether a team has learned something reusable or simply closed another issue.

The questions differ, but the dependency is similar: useful action waits for context. Adding more documents does not automatically reduce that delay. A larger collection can also make it harder to distinguish current guidance from an abandoned experiment.

What I mean by a second brain

For this talk, a second brain meant a maintained body of context that helps a team continue its work. It includes decisions and their rationale, incident history, runbooks, known limitations, and commitments that need follow-through.

The useful distinction is between storing information and maintaining it. A stored note can remain available long after its assumptions have expired. Maintained knowledge has a visible source, an owner, a verification state, and a reason to revisit it. It can be corrected or retired.

The recurring flow in the talk was:

Capture → Govern → Surface → Decide

Capture brings in relevant observations. Governance determines what may persist and who can use it. Retrieval surfaces the right material with its supporting evidence. A person then makes the decision with enough context to understand the consequences.

This also changes how I think about expert dependency. An experienced engineer’s judgment is valuable, but their availability should not be the only route to the team’s history. Shared memory can give another engineer the sources, reviewed guidance, and prior investigations needed to make progress.

It does not reproduce the expert. It preserves a better starting position for whoever is doing the work next.

Give AI the maintenance work

A large part of the talk concerned the division of responsibility. AI is useful for extracting candidate decisions, linking related cases, drafting summaries, noticing stale guidance, and bringing open questions back for review.

Those tasks consume attention, especially when context is scattered across messages, meetings, documents, and alerts. An assistant can prepare the material continuously, leaving people with smaller, more specific decisions to make.

In the personal workflow I described, Google Chat is the interaction surface, MyClaw is the agent runtime, and human-readable Markdown in Google Drive holds durable memory. The runtime coordinates tools, policies, and scheduled work; the underlying model is one component of that system.

The particular products matter less than the arrangement. People need somewhere to review and correct proposed memory. Durable records need to remain understandable outside a single chat session. Cases, decisions, and approved knowledge need different lifecycles.

A useful record should explain where it came from, who owns it, when it was checked, and what would make it questionable again. That gives the next reader a way to assess it instead of accepting a confident summary at face value.

Five loops that keep memory useful

I organized the maintenance work into five recurring loops. Together, they turn a collection of notes into something a team can keep using.

1. Capture decisions for review. After an architecture discussion, the assistant can extract the decision, its rationale, and the condition under which it should be revisited. A person can store, edit, or skip the proposal. Recording the reason matters: without it, a future team may preserve a decision after the original constraint has disappeared.

2. Assist with incidents. During an investigation, the assistant can surface a relevant playbook, its source, its verification state, and recent changes. The engineer chooses the next action. The assistant can preserve the checkpoint so the next handoff does not restart the investigation from scratch.

3. Draft weekly updates. Actual activity can become a draft of delivered work, ongoing work, risks, and next steps. Human review remains part of publication. This is valuable because an update should reflect what happened, including uncertainty, rather than merely sound complete.

4. Check freshness. Guidance should return for review when time passes, a dependency changes, or an original assumption stops holding. AI can identify those triggers. An owner decides whether the record remains valid, needs correction, or should be archived.

5. Propose reusable knowledge. Several cases may suggest a pattern worth preserving. The assistant can prepare a narrow proposal with evidence and limitations. A named owner reviews it before it becomes guidance for others.

These loops make maintenance a recurring responsibility. They also give the human reviewer a concrete question to answer at each step.

Discussing how AI can preserve context while keeping consequential decisions with people.

A resolved case is not automatically reusable knowledge

This was one of the most important distinctions in the talk. A fix can be correct for one incident and misleading when generalized.

A case records what happened under particular conditions. Reusable knowledge makes a broader claim: under these conditions, this diagnostic or action is worth considering again. Moving between the two requires evidence, scope, limitations, and ownership.

For example, a recovery procedure might have worked with one configuration. Before it becomes a runbook recommendation, someone needs to ask what actually explains the recovery, which prerequisites matter, and when the procedure should not be used.

The same applies to AI-generated summaries. Fluent language can hide how narrow the original evidence was. Promotion should therefore be an explicit action, with a reviewer responsible for the claim that future engineers will inherit.

Most cases can remain cases. Their history is still useful. Only selected lessons need to become shared guidance, and that guidance needs a path back to its supporting evidence.

Many cases, few promotions: reusable guidance needs verified evidence, a source trail, and an owner.

Making the boundaries concrete with a field-issue demo

I tailored the demo to KLA’s semiconductor engineering context: how AI could support an end-to-end workflow from a field issue to a tested code fix, with human approval at the consequential steps. The scenario is fictional and illustrates the proposed approach. The presenter application is a deterministic simulation backed by local artifacts and tests. It does not operate production equipment, call a live model, or deploy changes to an external system.

I see this as a practical example of forward-deployed engineering: working from a specific customer use case and shaping the AI solution around that customer’s environment. Here, the problem is moving from a semiconductor field issue to an actionable engineering investigation. The design follows the evidence available at the tool, the restrictions on sharing it, and the engineer’s responsibility for the fix. That customer context determines where AI can help and where human judgment must remain.

The automation workflow presented at KLA: raw evidence stays local, only an approved packet crosses the boundary, and an engineer reviews and ships the proposed fix.

The scenario follows evidence from a tool-side investigation to an engineering diagnosis. An on-tool agent prepares a sanitized packet while restricted raw evidence stays local. The packet must be reviewed and approved before it crosses the boundary to the engineering side.

One deliberate step is attempting the transfer too early. The system refuses it. That refusal makes the permission boundary visible: information being useful does not, by itself, authorize sharing it.

On the engineering side, the approved packet is combined with shared knowledge, code, and tests. The example concerns a settle gate that checks position while motion is still unstable. The workflow prepares a diagnostic experiment and a proposed runtime and test change. The engineer retains responsibility for reviewing and shipping the change through the normal process.

A second gate appears after the simulated resolution. The workflow refuses to promote the finding into reusable knowledge until an owner approves it. The later cold-start view shows what another engineer could inherit months afterward: a scoped diagnostic path, evidence, ownership, and review conditions.

This is the behavior I wanted the demo to make tangible. Better context can shorten the route to an investigation, while explicit gates preserve responsibility for sharing, software changes, and future reuse.

In a real implementation, those gates also require technical enforcement through credentials, isolation, network controls, validation, and audit records. A prompt alone cannot provide that boundary.

Memory about people needs its own limits

Engineering context includes people, and that requires care. Remembering an agreed follow-up can help a team. Turning an impression into a lasting judgment about a colleague can cause harm.

The manager workflow in the materials separates fragments into three outcomes: remember, keep uncertain, or reject. A professional commitment may be appropriate to retain. A conditional statement must keep its condition. A speculative personal judgment should not become durable memory.

Consider the difference between “I can review this if the release work finishes” and “I will review this.” Removing the condition changes the commitment. An assistant that compresses the first statement into the second has created an inaccurate expectation, even if its summary reads naturally.

That is why visibility and correction matter. People should be able to inspect the source of a remembered claim, correct it, and understand the boundary around its use. Useful continuity depends on restraint as much as recall.

Start with one decision that keeps losing context

My proposed starting point was a small, thirty-day pilot around one recurring problem. Choose a decision where the team repeatedly reconstructs history, then define what better continuity would look like.

A recurring incident, an architecture decision log, or a handoff process could be a suitable starting place. Give it one owner, a clear boundary around what may be stored, and a measurable outcome.

The build path in the talk moves through four stages: define the job and stop rules, wire the workflow and failure handling, ground retrieval and human review, then add ongoing ownership and operational checks.

The tests should cover the memory contract as well as answer quality. Does the workflow reject unreviewed material? Does it preserve conditional language? Can a person correct a record? Does promotion require approval? Can the system show where its guidance came from?

Measure whether the next engineer reaches a justified decision sooner, whether handoffs lose less context, or whether fewer investigations restart unnecessarily. Counting stored notes or generated summaries tells us little about those outcomes.

What I wanted engineers to take away

Speaking at KLA’s Engineering Conference was an opportunity to connect AI with a familiar engineering challenge: continuity across people, incidents, and time.

The promise of a second brain is practical. It can help a team recover the rationale behind a choice, resume an investigation, and reuse an earned lesson with its limits intact. Reaching that point requires ongoing maintenance and deliberate human ownership.

My closing question was: Where does your team pay its highest memory tax?

That is where I would start. Find the context that repeatedly disappears, preserve it with evidence and boundaries, and see whether the next decision improves.

The talk repository contains the slide deck, speaker notes, and demo materials for exploring the approach in more detail.

Knowledge Management | Jacob Aloysious