AI | Jacob Aloysious

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.

Bringing My Blog Back with Codex Computer Use

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

My blog’s source code was sitting in GitHub. My domain, jacobaloysious.in, was registered with GoDaddy. I had a Vercel account ready to use. Somewhere in the background, an old AWS setup was still involved.

The goal sounded simple: publish the blog from GitHub using Vercel and make it accessible through my own domain.

This time, I asked Codex to help do the work through Computer Use. Instead of following a deployment tutorial and switching between dashboards myself, I let it inspect the browser, configure the deployment, and trace the domain setup. I stayed involved when access or missing context required my input.

It turned into a useful exercise in both AI-assisted work and remembering how my own website was wired together.

1. Get Computer Use working

The first obstacle appeared before deployment even began. Although I was signed in to GitHub, Vercel, and GoDaddy in Chrome, Codex could not initially connect to my browser.

The Computer Use setting showed:

Disabled by your organization or unavailable in your region.

The message alone did not establish the cause. We checked the available setup guidance, but did not conclusively diagnose why the setting was disabled. I subsequently enabled Computer Use and asked Codex to continue.

Once access was working, Codex could inspect my existing signed-in Chrome tabs and interact with the account dashboards.

The first lesson: being signed in to a website and giving an assistant access to that browser are separate steps.

2. Inspect the existing Hugo project

My Hugo source lived in a private GitHub repository.

Codex inspected the project and its existing GitHub Actions workflow. That revealed several details that mattered for the new deployment:

The site used Hugo with the Academic theme.
The theme was included as a Git submodule.
The existing build pinned a specific Hugo Extended version.
A custom icon was copied into the theme before building.
The previous workflow published the generated public directory to AWS S3.

Reading the old workflow gave us a starting point for a compatible build. There was no need to combine a hosting migration with a theme or Hugo upgrade.

3. Import the repository into Vercel

In the Vercel dashboard, Codex opened Add New → Project, selected GitHub, and selected my blog repository.

Vercel already had access to the repository, so it could import the private project without making the source code public.

The project configuration was:

Setting	Value
Framework preset	Hugo
Root directory	Repository root
Source branch	The production branch
Environment variable	`HUGO_VERSION`, matching the existing build
Build output	`public` through the Hugo preset

We overrode the build command to preserve the existing theme setup. The build initialized the Git submodules, copied my custom icon into the theme, and generated the static site with the intended production URL.

A simplified example of the Hugo generation step is:

hugo --minify --baseURL https://example.com/

Use your own domain in place of example.com, and include any preparation steps required by your theme.

4. Deploy and check the actual website

The first Vercel deployment succeeded. The blog became available at its Vercel-provided address.

Codex then opened the deployed site and checked more than the deployment success message. The homepage displayed my biography, profile image, styling, and recent posts. It also opened the Leadership - Buy In | Meetings article and verified that its content loaded.

At this point, the hosting part was working. The Vercel project was connected to GitHub so future pushes to the production branch could trigger new deployments.

5. Add the custom domain in Vercel

Next, Codex added jacobaloysious.in to the project’s production environment.

We kept the address without www as the main domain. Codex also added www.jacobaloysious.in and configured a 308 permanent redirect to jacobaloysious.in.

Vercel supplied the DNS records needed for this project:

Type	Name	Destination
A	`@`	The IP address provided by Vercel
CNAME	`www`	The CNAME target provided by Vercel

The destinations are intentionally generalized here. Use the exact records displayed in your own Vercel dashboard.

6. Discover the old AWS connection

I expected the next step to be editing DNS in GoDaddy. Instead, GoDaddy showed that the domain’s DNS was managed by Amazon Route 53.

That explained why registering the domain with GoDaddy did not mean GoDaddy controlled its active DNS records.

The services had different jobs:

Service	Role in this setup
GitHub	Stored the Hugo source and content
Vercel	Built and hosted the website
GoDaddy	Registered the domain; later became its DNS provider
AWS	Previously supplied Route 53 DNS and the S3 deployment destination

Codex initially suggested updating the existing Route 53 records to preserve anything else using that DNS zone. I clarified that I no longer used the AWS setup and wanted the website routed to Vercel.

That context mattered: it allowed us to replace the old nameserver delegation instead of requiring access to AWS.

7. Move DNS management back to GoDaddy

Codex selected GoDaddy’s default nameservers and completed the confirmation flow, moving DNS management back to GoDaddy.

Once the GoDaddy DNS records became available, Codex made two changes:

Replaced the parked @ A record with the IP address supplied by Vercel.
Changed the www CNAME to the target supplied by Vercel.

GoDaddy confirmed that both records were saved successfully.

Changing DNS and retiring the previous hosting setup are separate tasks. A migration should also include a review of old deployment workflows, credentials, and billable resources.

8. Investigate Vercel’s “Invalid Configuration” warning

After saving the records, Vercel still showed Invalid Configuration for both domain names.

It was tempting to assume we had entered something incorrectly. Codex compared the saved GoDaddy records with Vercel’s required values and ran public DNS checks.

The records matched, but the public lookups were still reaching the old AWS nameservers. Those servers refused the queries, and the lookups returned SERVFAIL.

So there were two different states:

In GoDaddy: the new nameservers and Vercel records were saved.
In the public DNS checks: the old AWS delegation was still being used.

Vercel could not verify the custom domain while those lookups were failing. A browser check also failed to resolve the domain, so we could not yet verify HTTPS on the custom address.

GoDaddy advised that most DNS updates take effect within an hour, but global propagation can take up to 48 hours. Saving a DNS change is not the same as every resolver seeing it immediately.

9. Verify the domain and go live

After the DNS changes propagated, the domain was verified and the blog became accessible at jacobaloysious.in.

The completed setup:

The Hugo blog was deployed and working on its Vercel address.
GitHub was connected to Vercel for future deployments.
The main domain and www redirect were configured in Vercel.
GoDaddy had accepted the nameserver change and saved the required records.
The custom domain was verified and the website was live at jacobaloysious.in.

The earlier Invalid Configuration warning was an intermediate state during the migration. Once the DNS change took effect, the main goal was complete: readers could use my own domain to access the blog hosted on Vercel.

What I learned from using Computer Use

The most useful part was watching Codex carry context across several services. It read the old build workflow, applied those details in Vercel, discovered the Route 53 dependency in GoDaddy, and used DNS checks to explain the remaining warning.

It also exposed where my input was necessary. I had to enable browser access and explain that AWS was no longer part of the intended setup. The assistant could inspect the dashboards, but it could not infer that decision from a nameserver entry alone.

There were practical limits too. Browser pages needed time to load, some interactions needed another attempt, and a successful save did not guarantee an immediately working domain. Verification remained part of the job.

For me, this was a concrete example of AI helping with an operational task: taking an existing website, understanding enough of its history to deploy it, and working through the connections between source code, hosting, registration, and DNS.

My blog is now live at jacobaloysious.in, with the content in GitHub, hosting on Vercel, and domain registration and DNS managed through GoDaddy. The old AWS nameserver dependency has been replaced.

For future posts, the publishing flow is simple: update the content in GitHub, push to the production branch, and let Vercel build and deploy the site.