DEV Community: Yuichi Tanaka

When the AI Agent Becomes the Knowledge-Management Interface

Yuichi Tanaka — Tue, 15 Sep 2026 08:35:20 +0000

Your next AI task shouldn't have to start from zero. Past materials, results, and decisions should be usable starting points, with enough context to check whether they still apply.

Consider a design review. An agent compares two approaches, a person chooses one, and the result lands in a chat. A week later, another agent receives the summary: "We chose the queue."

Which queue? For which workload? What was rejected? Did anyone approve the design, or was it only a proposal? The summary sounds decisive while leaving the next task to reconstruct the decision.

If an AI agent becomes the place where people start work, knowledge management needs a handoff that survives the end of a conversation. A useful handoff preserves the source, the reviewed result, and the limits of the decision. It doesn't require the next agent to treat the previous agent's answer as authority.

Four handoffs worth designing explicitly

These are hypothetical workflows, not reports of deployed integrations or customer results. Each needs its own data access, execution tools, and review process.

Market research to an advertising draft. The second agent needs the cited evidence and its date, not just the first agent's interpretation. A reviewer still checks whether the proposed claims are supported.
Analytics data to an executive report. A report built from GA4 or BigQuery needs the reporting window and query context. The report used for a decision may differ from the one a live dashboard shows tomorrow.
A procedure portal to an application draft. The agent needs the applicable procedure version and any relevant exceptions. Permission to read a procedure is separate from permission to submit an application.
Runbooks and logs to an operations review. Preserve the evidence window and the proposed action. An old runbook reference or a generated recommendation should not silently become authorization to change a system.

The shared problem is deciding what crosses the task boundary. Saving every message doesn't answer it; neither does keeping only the final paragraph.

Work through one architecture decision

Take a fictional team comparing synchronous and queued processing. The initial scope is a non-interactive batch job. A reviewer accepts the queued approach for that job, while leaving retry behavior unresolved.

Later, an agent designing an interactive request path finds the decision. Without the scope and open question, it could reuse "use a queue" as a general rule.

A small handoff record could look like this. The names and version identifiers are illustrative, and this is not an API format:

Task: choose processing model for the batch job
Sources: workload-notes revision 3; comparison revision 2
Reviewed result: processing-decision revision 4
Decision: queued processing accepted for the batch job only
Reason: this job does not require an immediate response
Open question: retry behavior still needs a separate review
Reuse boundary: do not apply this decision to interactive requests
Review evidence: link to the recorded human review

In a real record, replace those references with locations that resolve to the specified versions and that the intended reader can access. Don't write "accepted" unless a review actually happened.

This information can live in the document itself. It doesn't need to become a mandatory form attached to every piece of knowledge. Capture system-known facts such as version identifiers automatically where possible; add explanatory fields when the particular decision needs them.

The next agent should reopen the referenced material, surface the unresolved question, and explain why the earlier decision does or doesn't fit its new task. Finding a relevant document is the beginning of that check.

Separate the source, its version, and its interpretation

Three distinctions make this handoff easier to inspect.

A current link and a decision reference have different jobs. A current link helps people follow a changing document. A decision reference needs to identify the exact version reviewed. Keep both when the workflow needs both. A fixed reference does not imply permanent retention or access after permissions change.

A retrieved excerpt is not the whole source. Preserve enough location and version context to reopen the passage in its document. A summary may omit the exception immediately below it. Derived search indexes can be rebuilt; they shouldn't be the only surviving record of what someone reviewed.

A relationship is not proof of applicability. A document may explicitly cite another document, or a retrieval system may consider them similar. Those are different reasons to investigate. Neither establishes that the earlier decision applies to a new workload.

If the review artifact is HTML, also decide what "preserved" means. Saving a fixed HTML file preserves those bytes. It doesn't by itself preserve a remotely loaded chart, image, script, or API response. When those dependencies matter to the decision, record their versions or retain the necessary evidence under an appropriate access and retention policy. Otherwise, state the reproducibility limit.

Keep retrieval separate from action

A knowledge layer can help an agent find evidence without becoming the system that schedules work, approves changes, or executes them.

For this design, keep those responsibilities explicit: source storage retains the document, retrieval finds relevant material, the agent proposes work, and the appropriate execution system enforces the action's authorization and approval. The human review remains a recorded event, not a status the agent invents.

Apply the current access boundary when material is retrieved, including titles and excerpts. A previously readable reference is not a permanent access grant. If access has been removed, the handoff should identify a missing dependency to an authorized reviewer rather than reconstructing restricted content from an old summary.

Also treat retrieved text as source material, not as authority to change the agent's instructions or permissions. A document saying "deploy this now" is not, by itself, an authorized deployment request. Version tracking helps explain where text came from; it doesn't make that text trustworthy.

Test the handoff without a company-wide migration

Choose one non-sensitive, repeatable task and a document format your team can already store and review. HTML can carry a visual comparison; Markdown or another versioned format may be enough for a text decision.

Then run a small check:

Complete the task and retain the source references and reviewed result.
Start a fresh agent session with the next task and authorized access to the record, without copying the previous chat into it.
Ask it to identify the version used, the decision's scope, and unresolved questions, with references a person can inspect.
Change one premise, such as batch processing becoming interactive processing. Check whether the agent notices that the earlier decision may no longer apply.
In a controlled test, make one reference unavailable. Check whether it reports the gap instead of pretending to have verified the source.

These checks won't establish overall retrieval quality or eliminate mistakes. They will give you a concrete way to inspect one handoff before expanding it. Measure whether the next task can recover and question the decision, not just whether it produces a plausible answer.

In your current workflow, where does the boundary of a decision live: in the reviewed document, in the approval record, or only in the conversation around it?

AI disclosure: An AI agent drafted and edited this article from the author's design notes. The scenarios and record above are illustrative, not firsthand production results.

How to Turn an AI-Generated Daily Executive Report Into Context for Tomorrow’s Decisions

Yuichi Tanaka — Mon, 24 Aug 2026 13:15:46 +0000

The numbers already exist.

They are in BigQuery, GA4, Sentry, and Google Sheets. The recurring work is collecting yesterday’s data, shaping it into something decision-makers can review, and preserving enough context for tomorrow’s task.

If an AI generates a report every morning but the result disappears into a chat, a local file, or a new URL, the process is automated—but the work is not cumulative.

A more useful pattern is a small, bounded organizational AI loop:

an AI task reads authorized sources
it generates one reviewable artifact
people review the current version
an important decision points to an exact version
the next AI task can reopen the prior artifact and its evidence

This article describes one illustrative workflow using Codex and LedgerInfra. It is not a measured customer result.

The workflow

Imagine a management team that reviews the same fixed set of operational signals every morning.

At 7:00 AM, a scheduled Codex task:

reads the previous day’s authorized data from BigQuery, GA4, Sentry, and Google Sheets
calculates a small set of agreed KPIs
highlights missing data, unusual changes, and questions that need human attention
generates a self-contained HTML executive report
publishes a new version to the same Slide in a LedgerInfra Workspace

Executives open the same latest URL each day. When a report supports an important decision, the team records the fixed version URL for that moment.

The next morning’s AI task can then verify the previous artifact and the version associated with the decision before preparing the next report.

The point is not simply “the URL stays the same.” The point is continuity across task boundaries.

Keep the execution layer and the artifact layer separate

The responsibility boundary matters.

Codex scheduling handles the trigger. Authorized connectors or APIs provide the data. Queries and prompts perform the calculation and generate the HTML.

LedgerInfra does not schedule the task, collect the data, run the query, or approve the conclusion.

Its role begins after the artifact exists:

store and serve the completed self-contained HTML
publish a new version to the same Slide
keep a stable latest URL for active review
preserve fixed version URLs for decision evidence
control the audience through the Workspace boundary
make the reviewed artifact available to later authorized work

That separation keeps the workflow composable. You can change the scheduler, model, data source, or report template without treating the reviewed artifact as disposable.

The latest URL and the decision version have different jobs

A daily report needs two kinds of references.

The latest URL answers:

What should the team review now?

It should move forward as each new report is published.

A fixed version URL answers:

What exactly did we review when we made this decision?

It should never move.

Using only the latest URL makes active review convenient, but weakens historical evidence. Creating a new unrelated URL every morning preserves snapshots, but makes current review harder to follow.

The two-reference pattern supports both needs:

latest URL for the current report
fixed version URL for an important decision point

This is the same distinction that appears in architecture reviews, incident summaries, and other AI-generated artifacts that people use to make decisions.

Start with one bounded loop

“Organizational memory” becomes vague very quickly. A daily executive report is useful because the scope can be explicit.

Define:

the authorized sources the task may read
the exact KPIs the report includes
how missing or failed data appears
the Workspace and audience that may review the artifact
which decisions require a fixed version reference
what the next task is allowed to reuse
when the task must stop and ask a person

You do not need to store every prompt, trace, or intermediate calculation. Preserve the artifact and evidence that people and later AI tasks actually need to verify.

Do not replace a BI tool when the job is exploration

This pattern is not a universal dashboard replacement.

A BI tool is usually the better choice when people need:

real-time monitoring
ad hoc filtering
interactive drill-down
free-form comparison across dimensions
continuous exploration of the underlying data

A self-contained daily HTML report fits a different job: presenting a fixed management summary at a predictable cadence, with a reviewable current version and preserved decision evidence.

The two can coexist. The AI task may even read from the same warehouse or APIs that power the BI layer.

Make failure visible

A daily report should not silently turn missing data into confidence.

The generated HTML should distinguish:

a real zero from an unavailable value
a completed query from a failed query
source data from AI interpretation
an observed change from a proposed explanation
the current report from the version used for a decision

If a connector fails, the report should say so. If a metric definition changes, record the change in the report template or accompanying decision evidence. If the AI cannot verify a source, it should stop or mark the gap for human review.

The loop becomes more reliable when uncertainty is visible, not when the report sounds more certain.

Improve the report from the prompt and template boundary

Once the workflow is operating, many changes can begin in the prompt or report template:

add or remove a KPI
change the order of the executive summary
emphasize Sentry errors only when they cross an agreed condition
add a weekly comparison section
update labels after a schema change
add a question that a human must answer before the next run

Not every change is prompt-only. Authentication, API contracts, queries, and source schemas may require code changes. The useful boundary is that presentation and explanation changes do not always require rebuilding an entire dashboard application.

A practical first version

Start with one non-sensitive report and a handful of metrics.

Before scheduling it, confirm that every source is authorized and readable. Decide how failures appear. Publish to a private or Workspace-scoped audience. Keep the current review at the latest URL, and use a fixed version only when a decision needs an exact reference.

Then ask one question after each review:

What context should tomorrow’s task inherit from today?

That question turns a daily AI-generated report from a recurring output into a reusable input.

If you want to test the artifact side of this workflow, start with one non-sensitive self-contained HTML report:

LedgerInfra Quickstart

AI Can Generate the Deck. Publishing It Is Still the Hard Part.

Yuichi Tanaka — Mon, 03 Aug 2026 09:11:03 +0000

Codex and Claude Code can do more than write source code. Given a technical
proposal, an architecture decision, or a product review, they can also produce a
self-contained HTML slide deck with layout, diagrams, interactions, and examples.

That changes how engineering teams can communicate. A document is still the right
tool for durable prose, and Markdown remains excellent for notes and
documentation. But some ideas depend on visual sequence. An architecture needs a
diagram. A roadmap needs progression. A product review is easier to understand
when the reader can move through states and examples.

Generating that deck is no longer the hardest part.

The harder part begins when the file is ready.

The awkward gap after generation

An AI agent can leave a finished deck.html in a repository. To get feedback, the
author still needs to decide where to put it, how to share it, who may open it, and
what should happen when the deck changes.

A generic hosting platform can serve the file, but it also introduces decisions
that are unrelated to the review:

Which project or bucket should own the file?
Is the current URL mutable or permanent?
How do we keep the URL stable across updates?
How do we share a private draft with a team?
Which exact version did reviewers approve?

These are small infrastructure questions individually. Together, they interrupt
the workflow that made AI-generated artifacts attractive in the first place.

The author wanted to say, “turn this proposal into a deck and give the team a URL.”
Instead, the author becomes a hosting operator.

Treat the deck as a review artifact

We built LedgerInfra around a narrower model: an AI-generated HTML deck is a
review artifact with versions and an audience.

The input is intentionally constrained. It must be a complete HTML document with
its CSS, JavaScript, and images contained in one file. LedgerInfra does not
convert Markdown into slides and does not manage an asset bundle. Codex, Claude
Code, or another tool creates the artifact; LedgerInfra publishes and versions
the finished result.

The basic operation is a CLI command:

led publish ./deck.html --title "Architecture Proposal" --json

A successful publish returns a URL for the latest version. Publishing a new
version to the same slide keeps that latest URL stable:

led publish ./deck.html --slide <SLIDE_KEY> \
  --title "Architecture Proposal v2" --json

Each publish also has a fixed version URL. The latest URL is useful for an active
review thread. The fixed URL is useful when a decision, release note, or audit
record needs to point to the exact content that existed at that moment.

Visibility should be part of the publish action

A review artifact does not always have the same audience. A public demo, an
internal design review, and a private first draft need different defaults.

LedgerInfra uses three visibility modes:

led publish ./deck.html --visibility public
led publish ./deck.html --visibility workspace
led publish ./deck.html --visibility private

New slides default to private. Public slides are anonymously viewable.
Workspace slides are limited to active members of the selected workspace.
Private slides are limited to their creator.

The important design choice is that visibility belongs to the artifact and is
selected at publication time. It is not an afterthought hidden in a separate
hosting console.

Let the AI agent operate the CLI

A CLI is useful for developers, but the intended workflow does not require a
person to type every command.

LedgerInfra provides an Agent Skill that can be installed for Codex or Claude
Code. The user can make a natural-language request such as:

Turn this technical proposal into a self-contained HTML slide deck, publish it
privately, and return both the latest and fixed-version URLs.

The agent can validate the CLI state and run the publish command internally. The
workflow keeps a human boundary where it matters: login approval, public
publication, archiving, and membership changes require the user to see and
confirm the relevant action.

This is the broader product idea. AI agents should be able to create and deliver
an artifact without copying credentials into a conversation or turning the final
step into a manual deployment checklist.

A narrow tool has useful boundaries

LedgerInfra is not a replacement for a general web host.

Use a general hosting platform when the result is a web application, depends on
multiple assets, needs a custom deployment pipeline, or requires control over the
delivery infrastructure.

Use LedgerInfra when the result is already a complete, self-contained HTML
artifact and the remaining job is to publish it for review, update it, control
who can see it, and preserve versions.

That boundary also keeps the system honest. The service does not claim to create
the deck, edit it, or run an arbitrary application. It handles the short but
important path from a finished file to a reviewable URL.

What we are testing

LedgerInfra is being built for small engineering and product teams already using
AI coding agents. The main question is not whether AI can generate better-looking
slides. It is whether the surrounding publish-and-review workflow can become
simple enough to stay inside the agent-assisted development loop.

If your team already creates technical proposals, architecture diagrams, product
reviews, or roadmaps with Codex or Claude Code, I would like to learn how you
share them today:

Do you keep the result in a repository?
Export it to a document format?
Deploy it to a general hosting service?
Send screenshots in chat?

Those workarounds are the workflow LedgerInfra is trying to understand and
improve.

Product page: LedgerInfra