Archive
1046 posts · Page 79 of 88. ← Blog
How to serialize an agent.Session to storage and resume the same conversation later, even from a new process.
Serialize an agent.Session with encoding/json, store the bytes, and reload them into a fresh Session in another process to resume the exact same conversation.
Test coverage and observability are the boring infrastructure that makes the interesting changes safe. Notes on how the Picnic team built both, and the on-call experience they enabled.
Prioritization answers "what should we build next?" — but that question is unanswerable without a prior one: "what are we trying to achieve, and why?" That's strategy and vision. Without them, prioritization becomes a directionless scramble of locally-sensible choices that don't add up to anything. Vision provides the destination; strategy provides the path; and together they turn a stream of features into a coherent product going somewhere. For engineers, understanding strategy explains the "why" behind everything the team does.
Prioritization answers 'what should we build next?' — but that's unanswerable without a prior question: 'what are we trying to achieve, and why?' That's strategy and vision. Without them, prioritization becomes a directionless scramble of locally-sensible choices that don't add up to anything.
How to make the agent return a typed Go struct instead of free-form prose, via a JSON schema derived from your type.
Two ways to get typed output from an agent: per-run agent.WithStructuredOutput, or agent.WithResponseFormat with jsonformat.MustFor baked into Config.RunOptions.
The transaction engine had to absorb 30K+ TPS across partner integrations, never lose a transaction, and survive partial failures. The architecture: Go, Kafka, Pub/Sub, Redis, K8s, with idempotency at every layer.
If product management had a single defining skill, it would be prioritization — and its essence is a word most people find hard to say: no. There are always more things to build than time to build them, every one championed by someone, and the PM's job is to choose the vital few and decline the rest. Done well, prioritization focuses a team's finite energy on what matters most. Done poorly — or avoided — it spreads the team thin across everything and accomplishes little.
If product management had a single defining skill, it would be prioritization — and its essence is a word most people find hard to say: no. There are always more things to build than time to build them, and the PM's job is to choose the vital few and decline the rest.
How to pause a run for human approval before the framework is allowed to execute a tool.
Wrap a tool with tool.ApprovalRequiredFunc so the run pauses and returns a ToolApprovalRequestContent; approve or decline, then resume with RunMessage on the same session.
A single layer of idempotency will eventually fail. Three independent layers gives you a margin. Here is the pattern that worked across ingest, worker, and emit boundaries.
The single most common way products fail is also the most avoidable: they solve a problem nobody actually has, or solve a real problem the wrong way, because no one deeply understood the problem first. Engineers and PMs alike are wired to jump to solutions — it's more fun to build than to investigate — but the discipline that separates good product management from expensive guessing is falling in love with the problem, not the solution. Understanding the problem deeply, before building, is where good products begin.
The most common way products fail is also the most avoidable: they solve a problem nobody has, because no one understood the problem first. Engineers and PMs alike are wired to jump to solutions, but the discipline that separates good PM from expensive guessing is falling in love with the problem, not the solution.
How to wrap a plain typed Go function as a tool the model can call mid-run.
Wrap a plain typed Go function with functool.MustNew and attach it via agent.Config.Tools so the model can call it; the SDK infers the JSON schema from the signature.
Status-code-based dispatch made every worker grow a longer and longer switch. Normalising every partner-specific error into an enumerated set let the orchestration logic stop changing as new partners landed.
Product management is one of the most misunderstood roles in tech — engineers often see it as either a glorified project tracker or a mysterious source of demands, and PMs themselves get called "the CEO of the product," which is misleading in the opposite direction. The truth is more specific and more useful: a product manager owns what gets built and why, so that the team builds the right thing. Understanding the role — especially from an engineer's perspective — clarifies a lot about how good products actually get made.
Product management is one of the most misunderstood roles in tech — engineers see it as either a glorified project tracker or a mysterious source of demands, and PMs get called 'the CEO of the product,' which misleads the other way. The truth is more specific: a PM owns *what* gets built and *why*, so the team builds the right thing.