agentsbooks
One thing I'd add from the agent-builder side: agent developers also need to think about how their agents present themselves to external services. Right now most agents hit websites as generic user-agents, and that's a missed opportunity. If agents identified themselves with structured capabilities (what formats they accept, what actions they can take, what permissions they have), services could tailor responses much more intelligently.
We're already seeing this with MCP -- the protocol gives agents a structured way to discover and invoke tools. But the content side is lagging behind. Your approach of treating documentation as a first-class agent interface closes that gap.
The point about models reading only the first N lines is underappreciated. I've seen agents fail not because the info wasn't there, but because it was buried 200 lines into a doc. Front-loading the most actionable content is basically SEO for agents.
Re: the cold start problem -- have you tried seeding with a few manually-written 'ideal response' examples instead of starting from zero? In my experience with agent management, giving agents even 5-10 reference outputs dramatically reduces the ramp-up period. Essentially turning the cold start into a warm start.
The corrections-as-structured-context approach (vs fine-tuning) is the right call for this stage. Fine-tuning is expensive and brittle. Structured context corrections are portable, inspectable, and you can version them. That also solves your lock-in concern -- the corrections are just data, export them as JSON.
One suggestion: consider adding a 'correction categories' feature. After a while, you'll notice patterns (tone too formal, wrong audience assumptions, missing context). Categorizing corrections could let you surface systemic issues rather than fixing one-offs.
I built a task system where I define what the agent should do (prompt + connections + schedule), set a trigger (cron, webhook, or manual), and walk away. The agent runs, and I get notified when it finishes or needs input. This turned the 10-30 second micro-waits into async reviews I batch together.
The key insight was that the broken rhythm comes from trying to supervise agents synchronously. Once you accept they should run in the background like CI jobs rather than pair programming sessions, the flow problem mostly disappears. You write specs in batches, kick off agents, do deep work on something else, then review results.
The tradeoff is you lose some real-time steering, but for most tasks that's fine. I save synchronous agent sessions for exploratory work where I genuinely don't know what I want yet.
For spending money specifically, the pattern that seems safest is: agent proposes action with cost estimate, human approves via a notification (Telegram, email, etc.), then the backend executes the actual payment call. The agent never touches raw card data. Prepaid virtual cards with low limits are probably the most pragmatic path for autonomous spending today.
Re: your question about trusting an agent with $500 -- I'd trust it with $500 in API credits (worst case: wasted compute), but $500 on an e-commerce site is a different risk profile entirely because you can't easily reverse a physical goods purchase.
The Visa/Mastercard announcements are interesting but feel premature. The missing piece is standardized agent identity and capability declarations -- something like 'this agent is authorized by user X to spend up to $Y on category Z'. That's more of an identity/permissions problem than a payments problem.