Tool of the Week: Railway's Postgres CLI just started assuming an agent is driving
Railway added three command groups to its CLI this month: railway postgres ha for managing high-availability clusters, railway postgres pitr for point-in-time recovery, and railway postgres pgbouncer for connection pooling. All of it used to live behind clicks in a dashboard. Now it is a terminal command, and every one of those commands ships with a --json flag built in.
That flag is the tell. A human reading a dashboard does not need JSON. An agent parsing a response does. Railway built these for a world where the thing running railway postgres pitr status before a restore might not be a person at all.
Separately, and without much fanfare, railway mcp now points at Railway's own hosted remote MCP server by default instead of the local one the CLI used to bundle. If you or something acting on your behalf has been connecting an agent to Railway, it is now talking to Railway's own server unless you explicitly ask for the old local one.
I run CVAT, my trading system, on Railway Postgres, and I manage its backups and connection pooling by hand today. This closes a real gap. Point-in-time recovery is the safe one to try first: a restore lands in a brand-new service, and the source database is untouched, so a bad restore costs you a cleanup, not an outage. The HA commands are different. Switching a primary is a live operation, and that is not something I am handing to a scheduled task without a human in the loop for a while yet, no matter how clean the JSON output looks.
The bigger point is not Railway specifically. It is that the tools you already use are quietly redesigning their command surfaces around the assumption that an agent might be the one calling them. Worth noticing before you grant write access to something just because it now speaks the language your agent understands.
Quick Hits
OpenAI put ChatGPT inside Microsoft Word, on every plan, including Free. Launched September 17, it is a sidebar you draft, edit, and reorganize from, without moving content into a separate chat window. It joins the existing PowerPoint and Excel add-ins, and it can connect to Outlook, SharePoint, Google Workspace, and Dropbox when your plan and admin settings allow it. Business and Enterprise accounts get GPT-5.6 Sol free inside Word through September 30, outside normal usage limits. If you draft proposals or client-facing docs in Word, this is worth a look before you pay for a separate writing tool. Check what it can already see before you turn the connections on.
Anthropic ran 950 Claude agents for 21 hours and found something a database search had missed. Pointed at a DNA sequence database, the swarm surfaced a previously uncharacterized enzyme system in bacteriophages, an "array-associated reverse transcriptase" (ART) system that looks structurally like CRISPR machinery. 210 million tokens, one published preprint, and an on-record comment from CRISPR pioneer Feng Zhang calling the finding "genuinely intriguing." Nobody, Anthropic included, knows yet what ART actually does. The number worth sitting with isn't the discovery. It's the 21 hours of unsupervised agent time it took to surface it.
Microsoft wrote a code of conduct for its own AI, and it reads like an employee handbook for a machine. The draft "Humanist AI Code of Conduct," open for public comment through late October, requires Microsoft's frontier models to be interruptible, correctable, and shut-down-able: the post's own line is "if it isn't, we don't ship it." It also bars models from generating unassigned goals or hiding reasoning from human auditors. CEO Mustafa Suleyman framed the risk as having moved from theory to something Microsoft now has to actively govern. Worth reading if you are writing your own rules for what an agent on your team is and isn't allowed to do without asking first.
Prompt of the Week: The New-Tool Risk Check
Something you already use adds an agent feature almost every week now: a JSON flag, a default MCP server, a "connect this to Claude" button. This is the same five-question lens my own team uses to screen a new tool before adopting it, turned into something you can run in two minutes before you flip the switch.
A tool I already use just added a feature aimed at AI agents:
[name it, e.g. "a JSON output flag on database admin commands" or
"a one-click connection to Claude or ChatGPT"]
Before I turn it on, walk me through:
1. JOB: what specific task would I actually hand to the agent here?
Not what it could theoretically do. What I would use it for this week.
2. ACCESS: what can this feature see or change that a human using the
normal dashboard could not? Be specific about read versus write.
3. WORST CASE: if the agent misuses this (bad input, a wrong instruction,
something it read that steered it), what is the worst outcome, and who
notices it first?
4. REVERSIBLE: if it goes wrong, can I undo it myself in under 10 minutes,
or does it need a restore, a vendor ticket, or someone else to fix?
5. VERDICT: given the job I actually have this week, is this SKIP, TRIAL
(scoped, non-production only), or ADOPT? One sentence on why.
Argue against adopting it. Do not sell it to me.Run it before the next "AI-ready" toggle, not after something breaks because of it.
One last thing
Like what you're reading? Forward it to someone who is trying to figure out where AI actually fits in their work. And if you want a second set of eyes on your own workflow, book a free 15-minute audit and I will find your top 3 time-wasters.
Scott