What I own and what AI tools contribute.
I am a Senior Manager at LSL with more than 10 years of enterprise software and reporting experience. Since March 2026, I have extended that background into AI-assisted integrations, reporting workflows, and a personal agent stack.
- I own
- The problem definition, source decisions, priorities, controls, and acceptance criteria. I translate requirements into mappings and operating rules, direct the implementation, investigate failures, and judge the result against the requirement. I connect the work into a coherent process and check it against source records and the actual state of the application.
- AI coding tools contribute
- Implementation, analysis, tests, and review for Python tools, API integrations, and reporting components.
Selected internal work.
Workiva, an enterprise reporting platform, is a demanding setting for automation. Financial values, linked documents, changing sources, ownership, and presentation all have to agree. These examples come from internal reporting work.
Cash-flow reporting with recurring updates
A cash-flow report draws on many workpapers, and each update has to stay consistent with them. I directed an internal workflow that connects 11 workpapers to 12 report sections and 1,249 financial report cells.
The workflow keeps source references, assembles the linked spreadsheets and documents, and updates the existing report. It includes 69 arithmetic checks and 34 source comparisons.
The accepted result is an internal review workflow. Accounting acceptance and client release remain separate decisions.
Recovery rehearsal and export review
A controlled rehearsal refreshed changed inputs, then restored all 1,249 report cells in both the spreadsheet and the document, 2,498 numeric values in total. A separate review inspected 12 exported pages.
Municipal budget book and team intake
A budget book depends on many contributors, and each input has to reach the right place. I directed development of a 264-page internal budget book and an intake process that matches reviewed updates to the exact book section for each of 85 budget units.
The package connects financial inputs, linked outputs, charts, narrative review, and ownership of the next input. It combines the technical build with a process for multiple contributors.
Independent reviews accepted the internal handoff and the internal seven-file import rehearsal, covering update behavior, restoration, and presentation. That acceptance does not establish client release, staff adoption, or operation in the City workspace.
A faster update run with the same checks
In one matched Workiva update-and-validation benchmark, runtime fell from 58.3 to 13.4 seconds and API requests fell from 110 to 24. Both runs performed the same 48 checks. The gain came from changing how the work executes, including batching remote operations.
This result covers one matched operation. It does not establish whole-engagement time savings or labor savings.
Grading agents on application state
I developed a capability evaluation that graded agents against the actual Workiva state. Two agent configurations each passed all 7 predefined sandbox tasks. One task required refusing an inconsistent change, and both refused it correctly.
These are predefined sandbox tasks. They do not establish a general reliability rate for either configuration.
The personal agent stack.
My personal agent stack helps AI assistants recover context, use tools, carry out bounded work, and leave evidence of the result. I built and configured its integration and operating layers around existing models and agent runtimes. The stack is separate from employer and client work, though the reporting examples above apply the same methods.
- Roles and routing
- Codex, Claude, and the Hermes agent runtime each have a defined role, bounded assignments, and task-specific evaluations. Every task gets a capable agent, an owner, and a clear scope.
- Context and memory
- Repository memory, reusable skills, source references, and project records carry decisions and corrections into the next task. Agents have a place to recover the reasoning behind a requirement.
- Tools and integrations
- Workiva API and MCP access, a shared command interface, and Python tools give agents tested ways to inspect and change application objects. Stable operations move into reusable code.
- Execution controls
- Revision and ownership checks define what may change. Scoped changesets, records of the prior state, and recovery paths help reconcile a failed action or a response whose outcome is unknown.
- Evaluation and evidence
- Readbacks from the application, regression tests, capability graders, retained exports, and separate review compare actual results with the stated requirement. Each passing check states what it covers.
- Operating environment
- A shared server, isolated repository worktrees, route health checks, and handoff records tie the work to a known environment. They help the next session recover the work and its current state.
What changed as I learned.
Early approaches sometimes produced repeated coordination, one-off scripts, and reassuring status reports without closing the task. Those failures led to four changes.
- Make application access reusable. Agents kept repeating the same navigation and writing one-off clients. Shared interfaces and searchable operating recipes now give them tested operations instead.
- Make completion observable. Out-of-date inventories and agents agreeing with each other had caused rework. I shifted to reading current state, defining the intended change, and comparing the result with that expectation.
- Keep coordination proportional. Adding agents and proof files did not consistently improve delivery. I gave each assignment a separate area to change and grouped related edits into coherent changesets, with scripted prechecks where a model was unnecessary.
- Test the controls themselves. Review found defects in the controls, including rollback, link scope, cached verdicts, parsing compatibility, and preservation. I reproduced those failures, then directed repairs and regression checks before adopting the changes.
How I would start in a new role.
My strongest fit is with AI workflow, automation, and implementation teams that need to connect business requirements to working software and an operating process.
- Choose one recurring workflow. Its inputs, decision points, and outputs should be open to inspection.
- Map it with the people who use it. Identify sources, owners, exceptions, and acceptance criteria.
- Build a bounded agent workflow. Connect it to the necessary applications, put stable business rules into code, and keep judgment explicit.
- Test against the actual result. Cover normal, changed, invalid, and interrupted cases.
- Run a controlled trial before expanding. Work with the intended operators and measure completion time, correction effort, failed actions, and recovery. Those observations guide the next changes, training, and handoff.
Read more about my approachPublic evidence you can inspect.
These public repositories and the Krowbar demo use synthetic, mock, or fictional data, separate from the internal reporting work. Each project page states its scope and limits.
Testing accounting agents on reconciliation cases, with evidence checks, approvals, and failed-write recovery.
View repositoryReporting API access for AI agents, with OAuth, caller-supplied write confirmation, and tool-specific verification.
View repositoryA test of what happens when a write succeeds but its response is lost.
View repositoryA project workspace that helps people and AI assistants pick up work without rebuilding its context. The public demo uses fictional data and simulated updates.
Open the demo
My project index also covers Passal and Leasekite, where I own product direction, interface design, and implementation through AI coding tools. Each has its own scope and limits.
