memeri

Posting good job updates

Status: ✅ Current · Last reviewed: 2026-06-18

A job update is a one-line work-log entry attached to a job. Done well, it tells the next person (or AI) what changed and what's next. Done badly, it's a wall of text nobody reads.

What an update IS

"What changed since the last update, and what direction this job is moving in."

That's the whole brief. Like a git commit subject, but with structured evidence attached.

What an update is NOT

  • Not a spec or decision record. Those are other primitives.
  • Not a thinking dump. "I was considering X but maybe Y…" — write that elsewhere.
  • Not a chat transcript. No "let me first explain that I'm…"

When to post

  • After completing a logical unit of work
  • When blocked or direction changes
  • Before stopping or handing off
  • When a user asks for status

Don't post updates as a substitute for actually working. A job that gets 8 updates and 3 commits is mostly chatter.

The three layers

Every good update has these:

1. Summary (required, 1–2 sentences)

Outcome-focused. Like a git commit subject.

✅ "Implemented auto-evidence collection; next step is UI surfacing." ✅ "Blocked on sessionId propagation; needs gateway fix." ✅ "Fixed UUID comparison bug in job delete; deployed to Railway."

❌ "I started looking at the auto-evidence work and I think the approach might be…" ❌ "Done a bunch of stuff today."

2. Evidence (auto-collected when possible)

Files changed, commits made, commands run, tests passed, decisions made. The platform attaches some of this automatically (file edits via PostToolUse hook, MCP calls, tool execution events). For the rest:

  • For Claude Code: capture_work_evidence MCP tool buffers git output for the next update
  • Otherwise: pass details: { files_changed, commits, decisions, ... } directly to add_job_update

3. Interpretation (optional)

Only if the next reader genuinely needs context to make sense of the change. Most updates don't need this.

Importance levels

  • low — minor progress, FYI
  • medium — normal work (default)
  • high — blockers, decisions, milestones, anything someone needs to react to

high mirrors the update to the project-level timeline. Use sparingly.

Event types

Most updates are progress (default). Special types worth knowing:

  • work_completed — final update before transitioning the job to done. Should include commits + decisions.
  • blocker_created / blocker_resolved — dependency or external block, mirrors to project timeline
  • milestone_completed — significant achievement, mirrors to timeline
  • decision_changed — explicit pivot

A worked example

Bad:

"I worked on the diagnostics endpoint today. It's mostly done but I need to figure out the authentication. Going to look at how other endpoints do it tomorrow."

Better:

"Diagnostics endpoint scaffolded; next step is authenticating against the existing token middleware."

details:

  • files_changed: src/routes/diagnostics.js (+225)
  • decisions: ["Endpoint mounted on platform server, not gateway, for direct DB access"]
  • followups: ["Wire authenticateToken middleware", "Add per-source health classification helper"]

The second one is scannable, attaches the evidence, and the next reader (you tomorrow, or another AI) knows exactly where to pick up.

What auto-attaches

If your AI is using the Memeri MCP gateway and has a job binding (bind_ai_client_to_job), the platform automatically tags every tool call with the stream (workflow) + job. That means file edits, bash commands, and decisions surface without you having to remember them. Trust the system to attach evidence — focus your update text on the summary layer.

Cross-references

  • Working With Agents → Conversations are agents — the durable unit your updates attach to
  • Using Memeri → The Project page — where high-signal updates surface on the timeline
  • Using Memeri → Streams, Initiatives, Jobs & Todos — what a job is, and how updates fit