<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Jamal Yusuf</title><link>https://jamal.dev/categories/architecture/</link><description>Recent content in Architecture on Jamal Yusuf</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 10 Dec 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://jamal.dev/categories/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>The Go Advantage for Production Agentic Systems</title><link>https://jamal.dev/writing/go-advantage-agentic-systems/</link><pubDate>Wed, 10 Dec 2025 00:00:00 +0000</pubDate><guid>https://jamal.dev/writing/go-advantage-agentic-systems/</guid><description>&lt;p&gt;Agentic systems are distributed systems wearing a chat costume. The sooner you accept that, the fewer 3 a.m. pages you earn.&lt;/p&gt;
&lt;p&gt;I have been building Go backends since 2011 — Kafka pipelines, membership APIs, payment flows, the unglamorous center of enterprise operations. When multi-agent workflows arrived, I did not reach for a new religion. I reached for &lt;strong&gt;the same primitives that kept the event backbone alive&lt;/strong&gt;.&lt;/p&gt;
&lt;h2 id="why-go-for-agent-orchestration"&gt;Why Go for agent orchestration&lt;/h2&gt;
&lt;p&gt;Multi-agent workflows are coordination problems: fan-out, join, timeout budgets, partial failure, human escalation. Go&amp;rsquo;s concurrency model — goroutines, channels, context cancellation — maps to those problems without pretending parallelism is free.&lt;/p&gt;</description></item></channel></rss>