Projects |

Multi-Agent Development Workflow

Sun, 27 Sep 2026 00:00:00 +0000

For a website revision, I can give an agent the editorial guide and a set of pages, then review the resulting changes before publishing. That work happens in its own working copy, so another task can proceed without sharing the same files. The handoff carries the branch, changes, checks, and remaining questions.

Git calls these separate working copies worktrees. Each writing task gets one branch and one writer; a designated integrator combines finished changes. The files and staging areas are separate, but Git’s underlying history and branch references are shared. Isolation reduces accidental overwrites while leaving conflicts and incompatible changes for review.

The workspace’s routing guide assigns defaults by task. Claude handles architecture and decisions that depend on earlier context. Gemini handles pipeline operation, documentation, writing, and large source reviews. Codex handles routine code maintenance, tests, and Git mechanics. An explicit assignment can override those defaults—as it does when I ask Codex to revise these pages.

The routing instructions live in one shared document, linked from each agent’s entry file. That avoids maintaining three copies that can drift apart. Continuity comes from the context and records supplied in this workspace; it should not be assumed to be automatic or shared between products.

A completed task still needs integration approval. Its handoff identifies what was changed, what was checked, and what remains uncertain. A passing test suite does not establish that two independently sensible changes will work well together.

This remains a convention the participants must follow. Worktrees do not isolate a shared notes vault, an external service, or a sync process. The and describe the boundaries and approval rules.

Resume Manager

Wed, 09 Sep 2026 00:00:00 +0000

A useful tailored resume changes the emphasis without changing the experience. Resume Manager keeps a master record of my roles, projects, and accomplishments, then uses a job description to select relevant experience and rewrite its bullets. Employer names, dates, and locations are copied by code from the master; the model supplies bullet wording rather than rebuilding the whole document.

The most effective change was removing AI from the first step. My source resume already had recognizable sections, but model-based extraction misplaced fields and omitted information. A conventional parser that reads those sections reduced the recorded bootstrap time from over 90 minutes to about 1.5 seconds on my resume. Language generation remains useful for tailoring; it was unnecessary for reading a layout the code could recognize directly.

What tailoring can change

An illustrative example for a hypothetical applicant applying to a monitoring role:

Master: Prepared monthly monitoring reports in Excel covering 12 projects.

Tailored for a role emphasizing Excel: Prepared Excel monitoring reports for 12 projects each month.

The revised bullet puts Excel first while keeping the frequency, activity, and project count fixed. It adds no claim of managing those projects or improving their results. That is the kind of distinction I still review in the actual output; fixed dates alone cannot protect every factual implication of a rewritten sentence.

The ordinary workflow uses a saved job description and a local model. Optional questions let me explain priorities before tailoring, and the application folder keeps that guidance alongside the job description, draft, PDF, and validation report. A separate route can interpret a rough opportunity description and request a cloud-based relevance brainstorm. That route may send resume material to Gemini; the saved-description route does not require it.

Check what survived the rewrite

Checks flag possible invented or dropped numbers, repeated openings, similar bullets, and some unsupported responsibility wording. Explicitly supplied facts can include required phrases or acceptable alternatives, making omissions easier to spot. These are advisory checks, not a full understanding of whether the resume is faithful.

The September 2026 application trials showed why that matters: a rewrite dropped a financial figure, and another output omitted qualitative guidance despite a clean numeric report. Newer checks cover more of those cases, but word matching and similarity tests can still miss changes in meaning.

Page fitting ranks candidate experience and measures rendered drafts against a target length, so content selection responds to the available space. I still inspect the final PDF for readable layout and omissions. The master remains maintained by hand, and tailoring never submits an application. The explains the current entry points and review outputs.

Novel Omnibus Normality Test

Sat, 22 Aug 2026 00:00:00 +0000

My mathematics thesis explored a way to test whether data depart from a bell-shaped, or normal, distribution. It transforms an ordered sample into a pattern of departures from what normal data would produce, then looks for structure beyond random fluctuation. The aim was to detect different kinds of departure through one flexible test.

In the small-sample simulations, the method performed similarly to the established Shapiro–Wilk test for two families of distributions, but fell behind for two others. The result was a proof of concept with room to investigate the construction further. It did not establish a generally stronger normality test.

Turning a sample into a pattern

An ordered sample contains information about where it departs from the expected shape. After the transformation, normal samples fluctuate around zero. Other distributions can produce a systematic bend or a different pattern of departures. Keeping their direction as well as their size is the useful part of the approach.

I fitted those departures with a penalized generalized least squares model, or PGLS. The penalty discourages the model from simply tracing every noisy point, much as smoothing a jagged line can reveal its broader shape. The model also accounts for how the transformed observations vary together. Its fitted coefficients supply a measure of departure, and simulations of normal samples establish a rejection threshold.

What the simulations showed

The comparison used samples of 20 observations and 10,000 simulations per tested setting. Power is the proportion of non-normal samples a test correctly identifies under those conditions.

Simulated distribution	Proposed test compared with Shapiro–Wilk
t-distribution	Similar, generally slightly lower power
Generalized Pareto	Similar patterns across the tested shape settings
Gamma	Lower power, by about 10–20 percentage points in the reported comparisons
Chi-square	A larger gap, favoring Shapiro–Wilk over most tested settings

As distributions became harder to distinguish from normal, detection became difficult for both methods. The describe these conditions and the remaining choices: how strongly to smooth, which patterns to fit, and how to construct the final statistic.

This was my master’s thesis at Indiana State University, advised by Dr. Mark Inlow. The includes the report and R implementation.

Academic Hub

Tue, 01 Sep 2026 00:00:00 +0000

As a PhD student, a common problem is having too many learning resources and not enough time to explore them all. Synthesizing information from textbooks, lecture slides, recitation notes, past exams, and external content and distilling the most important lessons is a massive challenge, especially for multiple overlapping courses. A question I jotted down during lecture in my handwritten notes may require leafing through a textbook index, cross-checking against the notation used by my specific faculty, and connecting back to an example from a past semester’s problem set. Online searches or generic AI responses are faster, but lack the specific context from my own materials; usually LLM responses are based on other disciplines or invoke concepts far out of scope for my course.

My solution is the Academic Hub: a complete system for organizing my notes and course materials in a machine-readable format that a locally based AI agent can use to serve as my personal librarian and tutor. An interconnected group of customizable coding pipelines take my disorganized notes, slides, and syllabi and turns them into a fully searchable corpus of data, complete with metadata tags, which a local or low-cost AI model can use to generate customized study guides, practice problems, and Socratic tutor agents. The entire system is built to be reproducible for any course and any type of input: handwritten notes, slides, scans of textbooks, typeset PDFs–just drop a collection of study materials into a course directory, use a local agent to run the conversion and tagging pipelines, then start building custom materials from the resulting knowledge corpus. The system is also built to prioritize free or low-cost methods for transcribing content, relying on local LLMs or subscription models where possible and falling back to APIs if necessary, to ensure complete customizable to the user’s cost sensitivity and preferred LLM environment.

The common foundation for every course is a collection of materials transcribed into a machine-readable format, typically markdown or JSON databases. Converting notes or slides preserves the text, mathematical notation, and page context; the makes that material searchable by a local agent or using backlinks in a notes aggregator like Obsidian. From there I can ask a question, develop custom study guides, or explore how course concepts depend on one another through interactive concept maps. Creating this as a customized local pipeline rather than relying on a commercial study system or a cloud-based retrieval-augmented generation approach like Gemini’s Notebooks gives me complete flexibility to create and modify my own study tools, without worrying about releasing potentially copyrighted material to a third-party.

Prepare the materials

preserves equations, figure descriptions, and page references; handles shorter documents and handwriting.
flags suspicious extracted text and compares it with source images before changing it.
turns lecture recordings into study notes. Reliable references from each concept back to its exact moment in a video remain unfinished.

Find an explanation

uses retrieved passages to answer a question with references I can open and check. I can save an answer or a session recap as a study note; can return to its recorded passages to develop the explanation further.

uses the shared source material to map relationships between ideas, including the assumptions that make a conclusion follow. Its first full graph covers part of a microeconomics course. A graph helps trace those dependencies; a guide explains a topic in sequence. Both contain drafted material that needs review.

Study and practice

starts from a topic list, selects indexed sources, drafts a guide, and proposes edits for review. Its optional enhancement step adds the same fuller explanations and worked examples available to an existing summary.
gives hints and feedback on an attempt. The separate tracks progress during a conversation, but its strict checks have struggled with teaching unfamiliar material.
keeps my reasoning, agent derivations, and tutoring work distinct for comparison.
stores extracted exercises with their provenance. currently retrieves its own style examples; integration with that stored bank remains separate work.
can accompany an explanation, while turns notes into spoken episodes. A generated chart or recording still needs checking for its intended use.

Maintain the collection

keeps working notes available across devices. reports missing or stale outputs for review, and helps prioritize the next work.

The links to each tool’s current evidence and limits. A useful study session still involves choosing the material, checking coverage, and comparing generated explanations with their sources. The shared source trail makes those checks possible; it does not settle whether an explanation is correct.

AI Research Assistant

Tue, 01 Sep 2026 00:00:00 +0000

AI Research Assistant brings paper discovery, document conversion, and search into the same research workflow. It can compare candidate abstracts with a description of my research question before trying to obtain the full articles. Converted papers can then be searched alongside my own research notes using the tools developed for Academic Hub.

For an illustrative research question such as “How do researchers measure displacement after a disaster?”, the starting point is more specific than a keyword search for disasters. I can ask the discovery tool to favor empirical measurement over policy commentary, then inspect the candidates before building a reading collection.

The three current tools handle different parts of that work:

. Search an academic-publication catalog by researcher or topic, then score abstracts against the research description using a model running locally. The tool tries several sources for full text and records papers that need manual retrieval. Finding a relevant paper does not guarantee access to it.
. Convert available PDFs to text with references back to their pages. The converter reuses the course-notes tools, choosing local extraction or AI transcription according to the document. Equations, figures, and imperfect extraction still need checking.
. Convert Word documents, including research ideas and application essays, while retaining headings and basic formatting. Their text and the papers enter the same search catalog, making it possible to look for a topic across both.

The shared can query the research collection and together. can use those retrieved passages for an answer with source references. Each collection keeps its own records, so a paper, my research note, and a lecture explanation remain distinguishable when they match the same question.

These tools support a literature review that I direct: choosing the question, reviewing papers, obtaining restricted articles, and interpreting the evidence remain part of my work. The give the current capabilities and limits of each stage.

Predicting Wheat Yields in New Environments

Sat, 22 Aug 2026 00:00:00 +0000

Choosing a wheat variety is partly a question of where it will grow. My master’s thesis tested whether satellite measurements of the environment and accessible machine learning tools could help predict yields where field-trial information is limited. I compared those measurements with field records, using wheat trials from CIMMYT, an international crop-research organization.

The results separated two questions that can easily get mixed together. Machine learning models outperformed the study’s linear mixed-model baseline on held-out observations. Satellite data helped that baseline, but the machine learning models performed better with the manually collected environmental data. A stronger model and a more accessible data source did not automatically make the best combination.

What was compared

Google Earth Engine supplied environmental measurements such as soil moisture, precipitation, and vapor pressure. Field records supplied another view of growing conditions and management. I also tested adding pedigree information describing relationships between wheat varieties.

Four approaches predicted yields: a Bayesian linear mixed model, random forest, gradient boosting, and a neural network. Fifteen percent of observations were held out for the final comparison, with varieties represented across that sample. This tests predictions within the study’s data; use in new regions would need further validation.

For a direct comparison using environmental data alone:

Environmental information	Random forest R²	Linear mixed-model R²
Field records	0.829	0.113
Satellite-derived data	0.746	0.243

R² measures how much of the variation in the held-out yields the predictions account for relative to predicting the average. It is not the percentage accuracy of an individual yield prediction. The gives the full comparison, including pedigree information.

Accessibility mattered too

The machine learning models ran on freely available Google Colab resources, though some calculations took hours. The mixed model’s large genetic covariance matrices required a specialized machine with roughly a terabyte of memory. Computing requirements were therefore part of the comparison, alongside prediction quality.

The code is public, but restricted pedigree data prevents full reproduction from public inputs alone. The project is a research proof of concept, with further work needed on location precision, model settings, and validation before using its predictions to make planting decisions.

This was my Spring 2020 thesis for UC Berkeley’s Master of Development Practice, advised by Professor David Zilberman. The contains the code and full report.