DEV Community: Lorry Zhang

Two Weeks of Study Notes: What Can an Agent Actually Tell Me?

Lorry Zhang — Fri, 06 Nov 2026 14:21:05 +0000

On Sunday evening, you want to know how much of the past two weeks went into reading about programming and how much into practice. The arithmetic is easy enough. The minutes live in a timer app, the topics in your notes, and the reason one practice session stopped in a task comment.

You can collect those entries, make a table, and hand it to an agent. Once is manageable; every Sunday it becomes its own task. A controlled script or business backend could submit a small, consistent record when each session ends; you retrieve those records at review time.

A table pasted today answers today's question. Next week's sessions will not automatically enter that conversation, and a chat summary is not a substitute for the original entries. Someone still needs to connect the recording tool; existing note apps do not suddenly sync themselves.

Agree on what a session means

Settle four things first: end time, topic, recorded minutes, and what "completed" or "interrupted" means. Does a break followed by more practice count as one session or two? Decide before collecting months of inconsistent entries. A controlled reporter submits each session to an external store; an authorized agent reads the details later. If a phone app collects the data, do not embed a long-lived write token in the app.

These seven records are invented, not actual user data. Dates use Singapore time (Asia/Singapore). Minutes are self-reported, not a measure of attention or mastery.

Week	Date	Topic	Time	Recorded outcome
Week 1	October 20	Reading	30 minutes	Completed
Week 1	October 22	Reading	25 minutes	Completed
Week 1	October 24	Coding practice	20 minutes	Interrupted
Week 2	October 27	Reading	15 minutes	Completed
Week 2	October 29	Coding practice	45 minutes	Completed
Week 2	October 31	Coding practice	40 minutes	Completed
Week 2	November 1	Coding practice	35 minutes	Interrupted

The calendar weeks are October 19–25 and October 26–November 1, 2026. In an authorized behavior-event schema, scene_type=learning and action_type=study_session could identify these records. Put the topic in a queryable target_id; store minutes and outcome in extra_params to read after retrieval. The October 29 session, for example, has target_id=coding, minutes=45, and outcome=completed. An actual report also needs the schema's required source and time fields and a valid write credential.

Query by scene_type, action_type, and time, then read the returned minutes. Nested keys inside extra_params cannot be used as direct filters, and the service does not automatically aggregate them. Adding up seven complete records is straightforward. Finding every session longer than two hours over six months would require multiple bounded queries and completeness checks, or a separately designed queryable field. Write and read permissions are separate; an accepted report may not be visible until asynchronous loading finishes.

If your notes are spread across apps, choose a trusted script to translate them, and decide what should never be uploaded. The full text of a personal journal adds little to this particular reading-versus-practice question.

Give each study session a stable session_id; here it identifies a study session, not an agent chat. Suppose the phone loses its connection after handing the record to a controlled reporter, which then retries an uncertain submission. Two accepted reports get different server-generated event_id values even though there was only one 45-minute practice session. When reading, flag records with the same session_id and check the source before adding them up as 90 minutes. That is a convention for your reporter and analysis, not a promise that ingestion automatically deduplicates retries.

What seven records can answer

Suppose all seven have loaded and the query has not hit its limit. You could ask:

Compare my study records from October 19–25 and October 26–November 1, 2026. Add up minutes by topic and show how much I recorded for reading and practice each week. Mark unrecorded days as unknown.

The agent can add the seven rows: Week 1 has 75 recorded minutes, 55 of reading and 20 of coding practice. Week 2 has 135, 15 of reading and 120 of practice. That is 60 more recorded minutes and a clear shift in the mix toward practice. Week 1 has two sessions marked completed and one interrupted; Week 2 has three completed and one interrupted. This is arithmetic over retrieved detail records, not a claim of server-side analytics.

Those totals include the 20- and 35-minute interrupted practice sessions: time spent before the interruption still counts as study time. Ask instead for minutes of completed coding practice and the answer changes to zero in Week 1 and 85 in Week 2 (45 plus 40). The records are identical; the definition of what to add has changed. That definition is worth stating in the question.

A narrower follow-up is possible: "Was practice concentrated on the weekend in Week 2?" October 31 and November 1 contain 40 and 35 recorded minutes, respectively. That is 75 of the 120 practice minutes recorded that week. It says where the logged time falls; it does not prove you were more focused on weekends.

The seven rows do not tell us the exact day the pattern changed or whether learning became more effective. An unrecorded day is unknown, not proof of no study. If a planned break was marked "interrupted" in Week 1 but only phone calls got that label in Week 2, even the interruption counts are not comparable.

If the query returns five entries instead of seven, find the missing two before drawing a conclusion. The service filters by receipt time; sessions reported late may fall outside the chosen window. Queries have time and result limits, so a longer history needs multiple windows and, where applicable, pages with a completeness check.

Before tracking anything else

Habits and spending raise similar questions, but renaming a study event does not create a ready-made finance feature. A spending record needs amounts, currencies, categories, and a rule for refunds. Count a transfer as spending and record it again at the receiving account, and a fast total is still wrong. Be particularly selective about reporting financial or health details, who may read them, and how long they remain available. Health records are no substitute for medical judgment.

Start by noting the topic, minutes, and outcome at the end of each session for two weeks. At review time, check that the records were all retrieved before comparing them. If you still have to reconstruct half your studying from memory, fix the reporting habit or integration before connecting another source.

Project website: https://d2ggep2t73r4ny.cloudfront.net/

Technical and business discussion: lorry@antlertec.com

When the 2 a.m. Sync Fails, What Should an Agent Look Up?

Lorry Zhang — Fri, 06 Nov 2026 14:19:52 +0000

Imagine a sync job that starts at 2 a.m. and has produced nothing by morning. You give its code to an agent and ask, "Where did it get stuck?" It can find the timeout handler and retry settings. To find out how long this run lasted or how many times it retried, it needs a record from the run.

Logs and dashboards probably contain some of those facts. Manually pulling them into a chat is fine once in a while. A nightly job benefits from a fixed reporting convention, though: by the time something fails, you should not have to hunt through old logs to learn how long the previous run took.

The job can report a few key events as it runs, and an external system can retain them. When something goes wrong, the agent retrieves records by job ID and time. Those details do enter its analysis context, so decide which fields are safe to report and who can read them.

Record the moments that matter

Record the start and end of a run, its outcome, duration, and retry count. The job name nightly-sync identifies a series of executions; a different trace_id identifies each execution and connects its events. A scheduler restart should get a new ID. It should not be confused with an internal retry in the same run.

Define where a duration starts. If the job is scheduled at 02:00, waits a minute for a worker, and finishes at 02:02, you can report two minutes since scheduling or one minute of execution. Both can be useful, but they cannot be compared as if they were the same metric. In this example, duration_ms runs from actual execution start to the reported outcome and includes time spent waiting between internal retries.

The path is short:

Job or app --report event--> Validate and store --retrieve on demand--> Agent --analyze--> Person

An existing event platform may be enough. For small scripts and services scattered across systems, a shared reporting API is easier to govern than giving an agent direct read access to each production database. The agent gets a scoped read credential for the project.

Keep full logs in their usual place; they may contain secrets, customer details, and irrelevant stack traces. Report the small set of facts the agent will need: job name, run ID, result, and duration. Missing outcome data cannot be reconstructed later from a clever prompt.

Similarly, define retry_count as attempts made within this execution. If the scheduler starts a new process after a failure, that is another run, not an additional internal retry of the first one. A batch ID may be worth retaining with the event, but one placed in extra_params can only be read after retrieval. Frequent lookup by batch needs a planned queryable field.

Two nights, two outcomes

Both runs below are invented, not a real incident. On failure, nightly-sync submits an event under an active, authorized behavior-event schema:

{
  "schema_id": "default_behavior_events",
  "schema_version": 1,
  "data": {
    "report_source": "be",
    "client_time": "2026-11-05T02:02:00+08:00",
    "scene_type": "scheduled_job",
    "action_type": "run_failed",
    "target_type": "job",
    "target_id": "nightly-sync",
    "target_value": "timeout",
    "trace_id": "trace-job-demo-002",
    "extra_params": { "duration_ms": 120000, "retry_count": 1 }
  }
}

In this example, the November 5 job starts at 2 a.m. Singapore time and reports failure 120 seconds later, so client_time is 2:02 a.m. target_id is queryable. The duration and retry count in extra_params can be read after retrieving the record, but its nested keys cannot be used as ordinary query filters. The trace_id can connect this run to other evidence; a comparison with yesterday first requires that both runs use the same job identity and reporting convention.

The invented November 4 run also starts at 2 a.m. Singapore time. It reports run_completed at 2:00:45 a.m., with duration_ms=45000 and retry_count=0. These two reported durations differ by 75 seconds. They do not tell us whether the job has been slowing down all week, or which downstream service caused the timeout.

Check the job version, input size, and definition of completion before calling this a slowdown. Processing a hundred thousand rows one night and a hundred the night before changes the comparison. The schema has an app_version field if you need to track a job version. For input size, decide what is safe to report and whether it belongs in an extension attribute or a separately planned queryable field.

HTTP 202 acknowledges receipt by the message pipeline; the event may not yet be queryable. Save each response's event ID and server_time, then check again after asynchronous loading. Assume both receipts are within November 3 at 16:00 through November 5 at 16:00 UTC, the server-time window corresponding to November 4 and 5 in Singapore. A late report could be received after that window and would need a separate query.

If the reporting client disconnects before receiving the response, the state is less clear: the runner may have submitted the failure event without seeing the acknowledgment. Reconcile before retrying rather than declaring the platform missed it. Conversely, retrieving a run_failed event only tells you what the runner reported; it does not prove that every expected output row is absent.

Compare the runs

An engineer could ask:

Find nightly-sync events from November 3, 2026, 16:00 to November 5, 2026, 16:00 UTC. Compare the November 4 and 5 runs in Singapore time. List each run ID, outcome, duration, and retry count, then inspect where the timeout could occur in the code.

The agent uses its read credential to query by server time and target_id, then compares the records with the code's timeout and retry paths. In Codex, a configured MCP tool can provide that query. The Codex documentation covers the connection.

Assuming both events have loaded and the query has not reached its limit, the answer might be:

The November 5 run reported run_failed with timeout after 120 seconds and one internal retry. November 4 reported run_completed after 45 seconds with no retry. That is a 75-second difference. We still do not know which dependency stalled; check the failed run's logs and downstream calls using its trace_id.

The timeout branch in the code suggests where to look, but it does not prove this run passed through it. If the query is incomplete, the answer needs to say which records it actually saw.

Use the failed run's trace_id to find its execution logs. Did the internal retry occur before a connection was established, halfway through reading, or while writing the output? A slow dependency, a timeout threshold set too low, and queue time mistakenly included in execution time could all surface as target_value=timeout. Timing for the corresponding downstream call is what would let you narrow the cause.

Check trace_id before comparing counts. A scheduler restart is a separate execution; mixing its duration and retries with the first run would corrupt the diagnosis. If a query fills its limit, narrow the window or raise the total within the policy and follow a returned cursor for subsequent pages.

Test the failure paths first

In this example, duration_ms and retry_count live in extra_params. You can inspect them after retrieval but cannot filter directly on those nested keys. A standing question such as "which jobs ran longer than two minutes?" needs a queryable field or another analytics path. Keep reporting and reading credentials separate, and keep secrets and unnecessary personal data out of the event. The current production defaults cap a page at 100 rows and a time window at 31 days. You can query several windows, but that alone does not turn detail records into a trustworthy aggregate trend.

The meaning of run_completed matters too. It should mean that this execution finished according to the runner's contract. If the business question is whether the synced data passed a completeness check, report that check separately. The 45-second success record alone cannot establish that every output row was correctly stored the night before.

Use a dedicated job to report one success and one failure. Save both 202 receipts, wait until the records are queryable, and ask the agent to compare them. Then delay one report and see whether it confuses "not visible yet" with "never ran." That small test says more about this workflow than a fluent incident summary.

Project website: https://d2ggep2t73r4ny.cloudfront.net/

Technical and business discussion: lorry@antlertec.com