I just cleaned up this account to focus on one thing: AI systems architecture.
I'm Việt Phạm — AI Solution Architect. Here you'll get the latest AI news, design discussions, and teardowns of real AI platforms and products — a concrete look at how things are actually built, not just theory. Specifically:
- How to design agent systems that actually scale in production
- Real lessons from enterprise AI integration projects
- Analysis of AI news through an architect's lens, not just headlines
No noise, no hype. If you're building or running AI systems, this is for you.
Follow along — a deep dive on multi-agent orchestration is coming next.
SpaceX and Nvidia just filed with the FCC for up to a million AI compute satellites in orbit. Before dismissing this as a PR stunt, the engineering case is more specific than "space is cool."
Each Starmind AI1 satellite runs Nvidia's Rubin GPUs and Vera CPUs, targeting ~120kW sustained compute, ~150kW peak. Two real physics advantages over a ground data center: continuous solar power in the right orbit (no day/night cycle to buffer around), and radiative cooling straight into vacuum — no water, no chillers, no thermal throttling on a hot day.
The tradeoffs nobody puts in the headline: radiation-hardened chips run behind commercial silicon, there's no walking in to swap a failed board, and every watt of compute still has to get its data down through a bandwidth-limited downlink. This isn't a drop-in replacement for terrestrial data centers — it's a bet that for a specific workload shape (compute-heavy, latency-tolerant, power-constrained on Earth), the tradeoff math flips.
First deployments targeted for 2027 out of the Gigasat Factory in Bastrop, Texas.
Genuine architecture question: what workload actually makes sense to run 500-2000km up instead of next to a power plant?
@Similarweb In the near future, X will become a globally popular social media platform one that offers in-depth knowledge, connects people worldwide, and provides opportunities to earn money.
The demo version of an agent system has one path: everything works. The production version needs at least four things the demo never had to think about.
A fallback layer — what happens when the primary model times out or returns garbage mid-task, not just "the API is down."
Observability that traces a single failure back to the exact step — which sub-agent, which tool call, which retrieved context — not just an aggregate error rate.
Guardrails that check outputs before they reach a user or a downstream system, especially for anything touching real data or real actions.
And a cost ceiling per session, because an agent stuck in a retry loop can burn budget a lot faster than a chatbot ever could.
None of these show up in a weekend prototype. All of them show up in the first production incident. What's the one you learned the hard way?
Chatbot serving and coding-agent serving are not the same engineering problem, and treating them the same is where a lot of inference cost goes to die.
A chatbot is mostly stateless — each turn is close to independent, so you can scale it like any other request/response service. A coding agent holds a growing context across dozens of tool calls in a single session. Every step re-sends (or should reuse) a huge prefix of prior context. That's a fundamentally stateful serving problem.
This is why disaggregated prefill/decode and prefix caching became the real story in serving infrastructure this year — separating the compute-heavy "read the whole context" phase from the memory-heavy "generate token by token" phase lets you scale each independently instead of over-provisioning one to compensate for the other.
vLLM, SGLang, and TensorRT-LLM all made different bets on this tradeoff. If you're serving agents (not just chat), the framework choice isn't about raw throughput benchmarks anymore — it's about which one's caching and scheduling model matches your actual session shape.
Curious what people are running in production for long-session agent serving specifically, not chat.
Everyone's still budgeting for more GPUs. The teams actually hitting a wall are hitting it somewhere else: memory bandwidth.
Long context windows plus agents that keep state across dozens of steps means the working set per session has exploded. You can have all the compute in the world sitting idle waiting on memory to feed it — that's the actual failure mode showing up in production agent infra right now, not undertrained models or slow GPUs.
This is why CXL (memory pooling/expansion across devices) and photonic interconnects are showing up in infra conversations that used to be pure GPU-count discussions. The question stopped being "how many GPUs" and started being "how fast can I move context in and out of memory without stalling the compute I already paid for."
Compute got the last five years of attention. Memory and storage are quietly where the next architecture fights are happening.
I’m currently leading the AI Agent Hub initiative at Vietnamese bank. We’re building a full GenAI capability landscape with 9 layers — from Experience & Gateway down to Runtime (Prompt/Agent/Orchestration), Knowledge, Model, MCP Tool Gateway, Data, Infra, and a strong cross-cutting Governance/Security/Approval layer (including Human Approval, Maker-checker, Risk Tier, etc.).
Our landscape clearly separates the three parts you mentioned in the post:
– Business logic (L1 Experience + Use-case Catalog + Context/Prompt)
– Harness (L3 Runtime: Prompt Runtime, Agent Orchestration, Workflow, Function Calling, Tool Planning, Session & Memory, Response & Approval)
– Infrastructure (L4 Knowledge + L5 Model + L6 Tools/MCP + L7 Data + L8 Infra)a strong cross-cutting L9 Governance / Security / Platform Ops layer.
Managed Deep Agents addresses exactly the “harness + infrastructure” challenges we face when taking agents to production in a banking environment.
Question is:
1./ How much of our L3 Runtime (especially Agent Orchestration, Tool Planning, Session & Memory, Streaming Response) does Managed Deep Agents currently cover?
2./ Human Approval and Response Format in our L3 are mandatory (maker-checker, multi-level approval). How does Managed Deep Agents support native pause/resume of the agent loop and the ability to inject approval gates?
3./ For L5 Model (LLM Gateway, Provider Adapter, Routing & Fallback, Model Catalog, Risk Tier, Model Card) — do you recommend banks keep this layer in-house or leverage LangSmith’s capabilities?
4./ Regarding L6 Tools (MCP Server/Tool Gateway + Bank Systems: Core Banking, CRM, ECM…): How mature is the current MCP implementation in Managed Deep Agents with respect to Permission Scope, Secrets/Vault, Idempotency, Transaction Limits, and Maker-checker requirements?
Most teams are still optimizing the prompt. The ones actually shipping working agents moved on months ago they're optimizing the eval loop instead.
Here's the shift: a good agent system isn't "write a great prompt, deploy, done." It's a loop — the agent acts, the outcome gets scored against a real eval set, the failure gets traced to a specific step (was it the tool call? the memory retrieval? the handoff between sub-agents?), and only THEN does the prompt or the routing get adjusted.
Prompt engineering optimizes one input. An eval loop optimizes the whole system, continuously, against real failures instead of your intuition about what "sounds right."
The bottleneck this exposes: most teams can build the agent. Almost none of them have a real eval set specific enough to catch where it actually breaks in production versus a demo.
If you're running multi-agent systems — what's your eval loop actually built on? Golden test cases, live traffic sampling, human review, or still mostly vibes?
X's new monetization rule & how to actually get counted
1/Big change coming to X monetization, biggest since 2024 imo.
Old Revenue Sharing program is closed to new applicants right now. Starting Sept 8, 2026, eligible creators have to re-apply under a new system called Original Content Rewards Program.
Here's what I've dug up so far 🧵
2/Core thing that changed: X stopped counting raw views.
An impression only counts when:
- Viewer is a paying X Premium account
- Post shows at least 50% on Home Timeline
So 500k views from free accounts basically = $0.
3/ Engagement weighting changed too.
Likes, replies, reposts, bookmarks, quotes from Premium accounts carry way more weight than the same action from a free account.
A creator with 50k Premium followers can out-earn one with 500k random followers.
Quality > quantity, for real this time.
4/ New program leans hard into original content: real analysis, real opinions, firsthand takes.
What gets excluded: recycled/copied content, and "engagement bait" — the reply-for-follow, tag-3-friends, RT-if-you-agree type posts.
5/ X is using Grok to catch copied content now, even with watermarks, new intros, edits.
If a post is flagged as a repost, the monetized impressions go back to the original creator, not the copier.
So low-effort paraphrasing other people's viral posts is pointless now.
6/ So what's the actual play here?
- Write it in your own voice, don't reword someone else's viral post
- Longer threads with real substance, keep people reading past that 50% visibility mark
- Post when your Premium-heavy audience is actually online
7/- Bilingual posts (VN/EN) to reach Premium users across markets
- Reply with something useful under posts from credible accounts in your niche, don't just drop links
- Don't buy followers or use bots — X penalizes hard, even for "legit" 3rd party tools
8/ Bottom line: the old game of farming viral junk for views is over.
X is now paying people who write with real depth and can hold a paying audience's attention.
Chasing big numbers isn't the strategy anymore. Chasing the right people is.