DEV Community: Danil Galeev

A weekly reporting workflow that stops when its sources are incomplete

Danil Galeev — Wed, 16 Sep 2026 13:18:03 +0000

A weekly report can contain plausible numbers and still be unsuitable for a decision. A missing support export or an old CRM snapshot changes what the report can honestly say.

I built a small reporting demo for MadeBy.Expert to make those conditions visible. It uses synthetic billing, CRM and support snapshots, deterministic calculations and a template narrative. There are no live integrations or language model calls in this version.

Define the numbers before automating the report

The sample distinguishes monthly recurring revenue from revenue collected during the week. Open pipeline is the unweighted value of open opportunities, not a revenue forecast. Support metrics distinguish unresolved tickets at the snapshot from tickets resolved within the reporting period.

Each metric includes a source reference and a definition. Those details give the reviewer something concrete to check against the input.

For a client workflow, I would agree on these definitions before connecting the source systems.

A missing source is a report state

The browser demo lets you switch between complete sources, missing support data and stale CRM data. The report keeps the metrics it can calculate, omits the unavailable ones and records a blocker. It does not substitute zero for a missing value.

The final state comes from that blocker list:

status: blockers.length ? "blocked" : "draft",

For this example, all three sources are required for approval. A snapshot is stale if it was captured before the reporting period ended or more than 24 hours before the report's asOf time. A future timestamp is rejected as invalid input.

Those are choices for this workflow. A daily operations report might need a tighter freshness limit; another report might be useful with an explicitly optional source. The thresholds need agreement with the person using the result.

Here is the actual test covering all three sources and both failure modes. It uses Node's built-in test runner and strict assertions. fixture() loads the synthetic input afresh for each case:

test("missing/stale sources are unavailable and block approval", () => {
  for (const kind of ["billing", "crm", "support"])
    for (const mode of ["missing", "stale"]) {
      const input = fixture();
      if (mode === "missing") delete input.sources[kind];
      else input.sources[kind].capturedAt = "2026-09-12T08:00:00Z";
      const r = buildReport(input);
      assert.equal(r.status, "blocked");
      assert.ok(r.blockers.some((b) => b.startsWith(kind + ":")));
      assert.equal(
        r.metrics.some((m) => m.sourceId === fixture().sources[kind].id),
        false,
      );
      assert.throws(
        () => approveReport(r, r.digest, "Demo reviewer"),
        /Blocked/,
      );
    }
});

The last assertion matters: reporting the problem in the output is insufficient if the approval function still accepts it.

Approval applies to one version of the report

The implementation computes a SHA-256 digest of the report content, which includes a digest of the input. A reviewer supplies the report digest when approving a local export. The approval function recomputes it and checks that the report is still a draft without blockers:

export function approveReport(
  report,
  digest,
  reviewer,
  now = new Date().toISOString(),
) {
  const { digest: stored, ...content } = report;
  if (hash(content) !== stored || digest !== stored)
    fail("Approval digest does not match the current report");
  if (report.status !== "draft" || report.blockers.length)
    fail("Blocked reports cannot be approved");
  if (
    typeof reviewer !== "string" ||
    reviewer.trim().length < 2 ||
    reviewer.length > 100 ||
    /[\r\n]/.test(reviewer)
  )
    fail("A named reviewer is required");
  return {
    ...report,
    status: "approved",
    approval: { reviewer: reviewer.trim(), at: now, digest },
  };
}

Here, hash is SHA-256 over JSON.stringify(value) and fail throws an error. This is an excerpt from the local prototype, not a standalone approval service.

Rebuilding the report after changing the input produces a different digest, so the previous digest cannot approve the new report. The tests also alter a calculated metric directly and check that approval rejects the modified content.

There are limits to this approach. The digest is a consistency check, not a signature or proof of who reviewed the report. The reviewer name is supplied as text; there is no authentication or authorization layer. The JSON serialization is also specific to this implementation, not a canonical format for independent producers.

A deployed approval service would need to establish the reviewer's identity and permissions, store the review event, and bind the delivery action to the approved version. Those parts are not implemented here.

The browser page shows the data conditions and report. The local runnable example handles approval and export; neither sends a report automatically.

Where AI could fit later

A language model might help draft commentary from validated facts. That is a possible extension, not an implemented feature of this demo. I would keep metric calculation, source checks and the approval boundary explicit regardless of how the narrative is produced.

The current prototype makes no claim about client time savings, live connector reliability or model quality. Those need measurement against an actual workflow.

Try the demo, including the missing-source and stale-source cases.

If your team assembles a similar report manually, describe the workflow: which tools supply the data, how often the report is needed, and who checks it. We can discuss whether a small paid pilot with clear success criteria fits.

Typed Contracts Between AI Agents: The Interface That Actually Breaks

Danil Galeev — Tue, 15 Sep 2026 05:44:04 +0000

Most multi-agent failures I've seen don't happen inside an agent. They happen between two of them.

When the handoff between two agents is treated as loosely structured JSON or implicit shared state, the interface is underspecified — and underspecified interfaces fail quietly.

A production handoff should be treated like any other API contract:

an explicit input schema;
an explicit output schema;
required and optional fields;
semantic constraints, not only valid JSON;
a clear rejection and fallback path.

A concrete example

A research agent should not hand an unstructured object to a scoring agent. It should emit something the scorer can actually validate:

class ResearchResult(BaseModel):
    subject_id: str
    evidence: list[EvidenceItem] = Field(min_length=1)
    source_count: int = Field(ge=1)
    confidence: float = Field(ge=0, le=1)

The scorer runs only after that result passes validation. That gate is the important part.

Probabilistic output, consequential action

An LLM output is probabilistic. A database write, an external message, or a business decision is an action. Those two steps should not be directly coupled.

Between them, put a deterministic gate:

Parse the model output.
Validate its schema and business rules.
Reject, retry, route to review, or stop the branch when validation fails.
Execute the action only on an accepted contract.
Record the handoff version and validation result.

Why it changes failure behavior

Without a contract, a missing field becomes a null value, the null becomes a misleading score, and the score becomes a bad CRM update. The symptom shows up several steps away from the cause, and by then the trail is cold.

With contracts, the same failure is localized: ResearchAgent -> ScoringAgent, field source_count, validation rule failed.

That is more than defensive programming. It is architecture for software systems whose internal steps are non-deterministic.

It gives staff engineers independently testable boundaries, helps principal engineers reduce coupling between teams and agents, and gives architects and CTOs a clearer way to reason about compatibility, ownership, and recovery.

The rule

Every probabilistic step that feeds a consequential action needs an explicit validation gate. Typed contracts are one strong way to define that boundary.

The model can be creative inside the boundary. The boundary should not be.

Where have you found the most valuable contract in an agent workflow — between agents, between an agent and a tool, or before the final action?

Building AI Agents That Actually Work: What Nobody Tells You

Danil Galeev — Fri, 04 Sep 2026 09:11:40 +0000

I've been building AI agents for a while now. Not chatbots. Not RAG demos. Real agents that take actions, make decisions, and run autonomously.

Here's what nobody tells you.

The gap between demo and production

Every AI agent framework shows you a 5-line demo that works perfectly. Then you deploy it, and it fails in ways you didn't imagine.

The reason is simple: a demo is a happy path. Production is a graph of failure states.

1. Observability is not optional

Your agent is only as good as your ability to see what it's doing.

When an agent makes a wrong decision, you need to know exactly why. Was it a bad prompt? A hallucinated tool call? Missing context from a previous step?

Log every thought. Audit every action. If you can't replay an agent's decision process, you can't trust it.

2. Tools are the bottleneck, not the LLM

Most people think the LLM is the hard part. It's not. The hard part is the tools.

Your agent needs to call APIs, read databases, write files, send emails. Each of those is a failure point. Network timeout. Auth expired. Schema changed. Rate limited.

Build your tool layer like you build a distributed system. Retries. Circuit breakers. Timeouts. Graceful degradation.

3. The context window is a trap

Long-running agents accumulate context. The more they do, the more context they carry. Eventually, the context window fills with noise, and the agent starts making bad decisions.

Strategies that actually work:

Summarization — compress old context into summaries, don't carry raw history
Structured memory — separate short-term (current task) from long-term (learned patterns)
Forgetting — actively prune irrelevant context. If it didn't matter in the last 10 steps, it probably won't matter now

4. Determinism is underrated

Everyone wants creative agents. What you actually want is predictable agents.

A creative agent that hallucinates a solution is useless. A predictable agent that follows a known pattern is valuable.

Design for determinism first. Add creativity as a controlled parameter.

5. The orchestration layer matters more than the model

You can swap GPT-4 for Claude or Gemini and your agent still works — if your orchestration is solid.

Good orchestration:

Clear state machine
Explicit error handling
Human-in-the-loop for critical decisions
Audit trail for every action

The uncomfortable truth

Building AI agents that actually work is not an AI problem. It's a software engineering problem.

The LLM is the easiest part. Everything around it — tools, observability, state management, error handling, orchestration — that's where the real work is.

And that's also where the real value is.

Your Agent Isn't Losing Memory. It's Rotting.

Danil Galeev — Fri, 28 Aug 2026 18:33:00 +0000

Agents don't forget because the model is bad. They forget because we built it into them. Six hours and forty messages in, what an agent needs is gone — or still there but wrong, drowned in noise.

That's context rot.

I've spent the last month inside a team of always-on AI agents that run for weeks. Different jobs, one codebase, one shared vault of lessons. They review each other's PRs, publish, plan. And they rot. I watched every flavor of it, then built the countermeasures.

What context rot is

Four failures that compound.

Compression loss. When a session runs out of window, a summary replaces raw history. It sounds fine until the agent needs the detail it summarized away. I watched an agent repeat a plan that contradicted a decision two screens earlier. Nobody noticed, because the contradiction lived at a depth that was gone.

Drift. Each turn pulls the agent toward the recent and the loud. Given ten pieces of context, it weights the last five. Over hundreds of turns it quietly solves a different problem than the one you assigned.

Priority blurring. "We decided X" and "we looked at X" feel the same in the tokens. Decisions stop being binding and become suggestions.

Noise accretion. Stale output and dead ends pile up. The signal-to-noise ratio falls, and a degraded ratio looks like a dumber model.

The part nobody warns you about

The cheap fix is "just enlarge the window." I built that reflex out of myself. Longer windows don't fix rot, they defer it — later in the timeline, larger cost per turn, and past some point the model does visibly worse than with a lean window. Remembering everything is a form of forgetting: the important thing drowns.

And rot is per-profile, not per-agent. In a team sharing a codebase, what agent A rotted away still matters to agent B. So the fix must live outside any single session. Memory in one agent's head dies with that session.

What actually works

None of this is exotic.

Summarize to executable facts, not prose. Emit decisions and constraints as explicit, fixed-schema entries the agent can act on. A good summary answers "what is still binding" before "what happened."
Move memory out of the session into a semantic index. Our biggest win. Keep lessons and decisions in a plain markdown vault, index with embeddings, and search returns meaning, not exact strings. "Offer-notification" and "pet-booking" are unrelated strings and near-identical problems; string search never connects them, the graph does — in milliseconds, on one SQLite file and a small local embedding model. No vector DB, no cluster, no bill. Don't ask one long-lived brain to do all the retrieval.
Turn knowledge into skills, not notes. A lesson read once and never referenced is a lesson that rots. The durable form is a skill: a procedure loaded on demand behind a trigger, pulled into context exactly when it applies and out the rest of the time. That's the difference between a memory of what to do and a memory of when to use it. The trigger is the part to get right.
Layer memory by half-life. Instant preferences live in a compact always-on store; entity facts in a structured store you can query; long-lived conventions in a vault you load on purpose. Each level has its own audit cadence, so the always-on layer never bloats and the deep layer never goes stale silently. Cap and prune the always-on store on a schedule: an always-on memory that grows forever is context rot in slow motion.

Patterns to rot-proof an agent

Whatever you pick, these hold.

Make forgetting visible. If a session drops something, drop it loudly: what entered context, what left it, why. You can't manage decay you can't see.

Bind decisions harder than facts. A decision needs a source, a status, an owner. A degraded decision is an incident, not a nuisance.

Retrieve, don't carry. Pull the relevant slice on demand instead of carrying a fat context everywhere. The leaner the working set, the slower the rot.

One source of truth for shared rules. When agents cooperate, conventions belong in one place anyone can read, not duplicated into private memory where they rot out of sync and you end up fighting three versions of the same rule.

Treat memory as code. Schema changes, evals, tests. The vault is source, the index is a produced artifact: rebuild it on a cron and never hand-edit it. A knowledge graph you can't rebuild from source is a liability.

The uncomfortable take

You never beat context rot. You manage it. Design so the cost of rotting is contained and observable, and so the source of truth survives the session because it lives outside it.

Our agents now run week-long cycles with far less decay than the first version at hour three. The difference was never a better model. It was admitting that an agent's context is a perishable working surface, not a mind, and engineering it that way.

I keep getting asked which framework solves this. The answer stays boring: write good compression, index for meaning, encode lessons as triggered skills, cap the always-on memory, and keep long-lived truth somewhere the agent can query and rebuild instead of carry. The agent will look cooler carrying everything. It will also rot faster.

So: how do you decide what an agent is allowed to forget, and how do you make sure it tells you when it does?

When Should You NOT Use an Agent?

Danil Galeev — Thu, 27 Aug 2026 19:21:36 +0000

Everyone is asking "should we use agents?" The real question is "when should we NOT?"

I keep seeing teams bolt an agent on because it's the hot thing — then discover they reinvented a state machine with worse debugging. Agents don't solve a problem by existing. They are a mechanism for deferring decisions to a runtime. When your inputs, tools, and failure modes are well-understood, that deferral buys you nothing but nondeterminism.

The architecture question is not "LLM or not." It is: where does the judgment boundary sit?

Three places the boundary lands

A single agent is a program. For a well-scoped task with a known toolset, you don't need a loop at all. You need a deterministic pipeline — with the LLM as one component, not the orchestrator.

The moment you need a loop, you're building a runtime. A runtime is a different beast. It has observability, tool permissions, credit and rate limits, and a way to explain what it did after the fact. That's not "more AI." That's distributed systems with a language model as the cognitive layer.

The expensive failure is capability you never signed up for. Agents surface things you didn't design for: open-ended tool calls, emergent side-effects, scale that hits budgets or audit. This is where maturity shows — not in the cleverness of the model, but in the constraints around it: entitlements, approval, observability, evals that cover the failure path, not just the happy path.

The tell

Most of what teams call "agent architecture" is a decision-making boundary placed in the wrong spot, papered over with more layers. If you reach for a framework, an orchestrator, a runtime — stop and ask what you're actually deferring, and whether that deferral is working or just making the system harder to debug.

A few heuristics I use before building:

Can the task be expressed as steps with a known order? Pipeline with the LLM as a step — not an agent.
Does the agent invoke known tools with expected outputs? A single governed agent, thin on top of a deterministic core.
Do you need to route mid-task to unexpected states? Only then a real runtime, and only if you accept owning its observability, limits, and audit trail as first-class work.
Is the failure non-recoverable? Then don't put an agent in the loop at all. A wrong tool call inside a runtime can hurt you faster than a slower deterministic path ever will.

Constrain before you automate. The agent looks cooler; it's also much harder to explain three months from now.

So: when you're scoping a new system, what makes you reach for a deterministic pipeline instead of an agent — or the other way? I'd like the rules teams actually run with, not the ones they present in talks.