标签：#cloud

​ Managing academic records , student enrollments and staff communication across educational institutions requires speed, reliability, and security. Legacy school management systems are often slow, difficult to navigate, and bogged down by bloated software architectures. ​At SkyBuild Technologies, we designed and developed EduSky (edusky.skybuildtechnologies.com)—a modern, cloud-native and multi-tenant school management platform engineered to streamline administrative workflows and deliver instant access to institutional data. ​Here is an insider breakdown of how we architected and deployed EduSky using a modern tech stack centered on React, Tailwind CSS, and Supabase. ​1. Core Platform Architecture & Key Features ​EduSky was engineered to solve the most pressing pain points faced by school administrators, teachers, students and guardians/parents: ​ Centralized Student & Staff Portals : Secure management of student profiles, academic histories, staff credentials, and class assignments. ​ Real-Time Academic & Report Management : Streamlined record-keeping for grades, subject performance, and automated term report generation. ​ Administrative Controls & Access Levels : Granular Role-Based Access Control (RBAC) ensuring administrative staff, teachers, and parents access only authorized operational data. ​Fast, Mobile-First User Interface: Built with a responsive layout optimized for desktop administration and mobile access on smartphone screens. ​2. The Technical Stack : High Speed, Zero Bloat ​Rather than relying on legacy web setups, we built EduSky using a modern, decoupled architecture designed for sub-second load times and high availability: ​ Frontend : React + Tailwind CSS ​Dynamic Component Architecture: Built using React for modular, maintainable UI components (data tables, form inputs, dynamic dashboards). ​ Utility-First Styling : Styled with Tailwind CSS to maintain a light footprint, rapid UI iteration, and responsive mobile-first views. ​ Optimized State

After development comes deployment - whether on-premise or on a cloud based environment. And then we face a simple question: how much resource should I assign to this system? What is the ideal numbers? If we get this wrong, we often need to go back time and again to fine tune - either to ensure our application is capable of handling the targeted load, or to avoid paying for resources we are not using. This article explains the approach step by step. So that we spend just enough time upfront to avoid spending exponentially more time and money at later stages. Who Is This For? This article is written primarily for developers. But if you are a manager or a CTO, there are sections written specifically for you. Feel free to jump straight there. 👉 If you are a Manager or Project Manager 👉 If you are a CTO or Architect For everyone else - the full article is worth reading top to bottom at least once. But if you are revisiting a specific topic, jump to whatever is relevant. Table of Contents Local is the Starting Point When Should You Start Thinking About Right Sizing? How Long Will This Actually Take? Start With What You Have - Your Local Setup Setting Up Your Load Generation - The Hammer The Cost of Testing - This Is Not Free Sizing Your Pod More Resources Per Pod or More Pods? Scaling - Easy to Set Up, Hard to Get Right Periodic Right-Sizing - You Are Not Done Yet Local is the Starting Point Local system is always where we start. To try things out, to check if things work. But 99% of what we test locally is the sunny day scenario. Does the MVP work? Does the happy path hold? Even if you're diligent enough to test negative scenarios, you're almost certainly not testing production-level load on your laptop. Which means you have no idea what resources your app actually needs when it matters . This is where the problem starts. On local, we routinely kill the heavy IDE, close browser tabs, shut down background processes -without ever stopping to ask: how much memory and CPU d

A practical validation view for metric intervals, dimensions, notifications, suppression, and operator action An OCI alarm can be created correctly and still fail as an operating control. The issue may not be the alarm object itself. It may be the metric interval, a wrong dimension, an unconfirmed notification subscription, an absence query that fires for the wrong reason, or a message that reaches the team without telling them what action to take. This article is written from an OCI readiness and validation point of view. It is not a step-by-step Console walkthrough. The aim is to identify checks that should be confirmed before an alarm is treated as Production-ready. 1. The metric interval does not match the metric emission frequency This is one of the easiest alarm issues to miss. OCI documents a troubleshooting case where an alarm fires and then clears at the next interval even though the last data point exceeded the threshold. The cause is that the alarm interval is shorter than the metric's emission frequency. For example, if a metric is emitted hourly, an alarm interval that evaluates every minute may not behave the way the owner expects. The readiness check is to confirm the metric's documented emission frequency and set the alarm interval at the same frequency or longer when needed. Validate: Metric namespace and metric name Emission frequency for the selected metric Alarm interval in the MQL query Statistic used, such as mean, max, sum, or percentile Expected FIRING and OK behavior during testing Evidence can come from a metric-documentation or chart review, the alarm query, and a test record showing expected state behavior. The question for the owner is direct: does the alarm evaluate data at a rhythm that the metric can actually provide? 2. Dimensions include the wrong resource, or exclude the right one A metric query can be technically valid and still point at the wrong scope. In OCI Monitoring, dimensions help narrow metric streams. That is useful, but

I wrote this for the All Things Agentic Hackathon. Every incident-response demo you have seen ends the same way: something breaks, the agent fixes it, everyone applauds. I want to show you the opposite. Here is my agent, at 95% confidence, having correctly diagnosed a bad deployment, deciding not to roll it back. That refusal is the whole project. The question underneath At 3am an alert fires. An engineer wakes up, reads several hundred log lines, correlates them against recent deploys, and rolls something back. Most of it is mechanical. It is an obvious target for automation. But "automate it with an LLM" does not dissolve the problem, it relocates it. The new question is: how much would you let an agent change in production without asking you first? Give it too little and it is a chatbot that writes summaries. Give it too much and one confidently wrong diagnosis takes down your service at 3am with nobody watching. I named the project Sonjomon — Bengali for restraint. The autonomy ladder An agent should not have one blanket permission level. How far it may act alone is a function of two things: how confident it is, and how much damage the proposed action does if that confidence turns out to be wrong. tier = f(confidence, blast_radius) OBSERVE record findings, take no action SUGGEST recommend to a human, do not execute APPROVE stage the action, execute on explicit approval ACT execute now, then verify independently A restart is medium risk — reversible in seconds. A rollback is high risk — it shifts production traffic, and a needless rollback during a real outage extends it. Deleting data is critical, and no confidence level unlocks it. Six conditions can only ever push the tier down, never up: the blast-radius ceiling, thin evidence, a similar action that just failed, a third attempt at the same fix, a stale incident, and a global dry-run switch. Nothing pushes it up. A wrong action is far more expensive than a missed one. Three things the model does not control It

I created this article for the purpose of entering the All Things Agentic Hackathon. TL;DR — An ADK output_key writes into the session of the agent that declares it. In-process that session is shared, so it looks like state flows. Across a RemoteA2aAgent hop it is the worker's session, and it never comes back. Nothing raises. Nothing warns. Every local run and every CI job exercises the working topology, so the failure is invisible to an offline test suite by construction — including at 100% coverage. The system that passed Bastion is a three-agent access-governance fleet built with Google ADK and A2A. An Orchestrator owns investigation state, an Access Auditor reads production IAM through a read-only identity, and a model-free Escalation Agent delivers validated count-only reviews. The local graph passed its configured core statement and branch coverage gate. Every branch, every seam. Then the same graph was split across deployed A2A workers, and an assumption that looked natural in-process became false. The boundary we had not modeled In-process, the previous step's result is simply there : # The Auditor declares output_key; the Orchestrator reads it back. report = ctx . session . state . get ( AUDIT_FINDINGS_KEY ) Deploy the same sequence and only the construction changes. The graph is identical: RemoteA2aAgent ( name = " access_auditor " , agent_card = card_url ( auditor , " access_auditor " ), description = " Reads the live IAM policy and flags anomalies. Read-only. " , httpx_client = private_a2a_client ( auditor ), a2a_request_meta_provider = _forward_investigation , ) output_key still writes. It writes into the worker's session, which never crosses back. The deployed Orchestrator saw an empty state key while every local run and every test saw a populated one. Observed 2026-08-22: the Auditor completed a full sub-trail, and the next step then refused with "returned no structured report." No exception at the boundary. No warning at construction. The run still r

Cloudflare KV for Session Caching in Multi-Tenant FastAPI: Reducing PostgreSQL Load Without Redis Complexity Every SaaS I've built hits the same wall: session validation on every request hammers PostgreSQL. You add Redis, suddenly you're managing another service, debugging cache invalidation, and paying for redundancy you don't need. Then I discovered Cloudflare KV sits between your users and origin server. It's not a replacement for PostgreSQL—it's a read cache positioned at the edge that auto-syncs on writes. For multi-tenant session and permission data, this eliminates 60–80% of auth-related database queries without the operational complexity of Redis. This is the approach I use in CitizenApp. Here's why it works, how to implement it, and where I nearly broke production. Why Cloudflare KV Beats Redis for Session Caching Redis requires: A separate service deployment (Render, AWS ElastiCache) Connection pooling logic in your app Cache invalidation strategies you'll get wrong Monitoring for memory leaks and eviction Cost that scales with your hot data size Cloudflare KV requires: A binding in your edge worker (one line of config) Simple key-value storage at 200+ edge locations Automatic TTL expiration Zero operational overhead—Cloudflare manages it Here's my honest take: I prefer KV because I don't have to think about it. My workers validate JWT tokens and fetch session data from KV before even routing to my FastAPI origin. Cache misses flow to PostgreSQL and write back to KV. No connection pools. No eviction policies. No debugging Redis memory fragmentation at 3 AM. The tradeoff? KV is slower than in-memory Redis (ms vs microseconds), but for session lookups happening 200+ times per second per user at global scale, edge-cached responses beat origin-fetched ones every time. Architecture: Edge Validation + Origin Sync Your flow looks like this: Request hits Cloudflare Worker Worker checks KV for session + permissions (hit = serve immediately) KV miss → fetch from Fas

As part of the Gen AI Academy APAC , I set out to solve a major pain point for educators: manually sifting through textbooks to create grade-appropriate question papers. I built an automated Question Paper Generator using a Serverless Next.js stack, a Retrieval-Augmented Generation (RAG) architecture, and the complete Google Cloud AI suite. Teachers simply upload a textbook chapter (PDF), specify the grade and subject, and let the AI generate a fully formatted assessment quiz. While the architecture sounds straightforward, orchestrating these enterprise-grade APIs in a serverless environment presented several intense technical hurdles. Here is a deep dive into the architecture, the specific roadblocks I hit, and how I ultimately solved them. 🏗️ The RAG Architecture The application is built on Next.js 15 and deployed to Google Cloud Run . The pipeline flows as follows: Document Extraction : The PDF is uploaded and sent to Google Cloud Document AI (Document OCR Processor) to extract the raw text. Chunking & Embeddings : The text is chunked into logical paragraphs and sent to Vertex AI ( text-embedding-004 ) to generate dense vector embeddings. Vector Database : The embeddings and metadata (Grade, Subject) are stored seamlessly in Firestore using native VectorValue support. Retrieval & Generation : When a teacher requests a quiz, the query is embedded, and a findNearest Vector Search runs on Firestore. The retrieved context is passed to Google Gen AI ( gemini-3.5-flash ) to synthesize the structured question paper. 🐛 The Technical Challenges & How I Solved Them Building an end-to-end pipeline using cutting-edge SDKs often means dealing with strict schema validations and opaque error codes. Here are the major technical gotchas I faced. 1. The Document AI Region Endpoint Mismatch The Challenge: I provisioned a Document OCR processor in the asia-south1 region. However, when my Node.js client attempted to send a processing request using the processor's full resource name,

Cloudflare Workers can now accept inbound TCP connections through a new connect(socket) handler routed via Spectrum, ending an eight-year restriction to HTTP. Containers get full-duplex gRPC in any language, while Workers get unary and server-streaming through automatic gRPC-web translation. Everything is private beta. By Steef-Jan Wiggers

I created this content for the purposes of entering the All Things Agentic Hackathon. The problem that started it A doctor gets about eight minutes with a patient and, for anyone with a real history, forty pages of scattered records — lab reports, discharge notes, and pharmacy bills from three different clinics. So the history is effectively invisible at the exact moment it matters most. And when the visit ends, nothing follows up: the six-month course lapses at week five, the recheck never gets booked. I wanted to build an agent that closes that loop — one that reads the mess, decides urgency in a way a clinician can actually trust, and handles the follow-up on its own. That became CareLoop , my entry for the All Things Agentic Hackathon (Taskmaster track), built on Gemini, the Google Agent Development Kit (ADK), Cloud Run, and Firestore. The one principle I wouldn't compromise on Rules decide, AI explains. The temptation with an LLM is to let it do everything — including deciding whether a chest-pain patient is urgent. I refused to do that. In CareLoop, a deterministic engine owns every clinical decision: a weighted symptom score plus a red-flag override sets the triage level and routing. It is fully auditable, and it returns byte-identical output on the same input every single time. The LLM's job is strictly language: Reading unstructured documents into a fixed schema — I call it "Gemini extracts, rules merge." Writing the structured result into a plain-language brief a clinician can skim in ten seconds. No language model is ever in the decision path. When a judge asks "why was this Critical?", the answer is a score breakdown they can inspect — not a model's say-so. That single decision shaped the whole architecture. What it actually does CareLoop runs the full loop end to end: Ingest & compact — it reads a patient's documents and merges them into one structured ledger: allergies, chronic conditions, active medications, and lab trends over time. Instead of pushin

--- title : " AI Harness: the worst and the best buzzword in the industry" published : false tags : [ ai , harness , middleware , finops , aws , bedrock , opensource ] series : " TokenOps on AWS" cover_image : # TODO: circuit-breaker / middleware diagram --- AI Harness: the worst and the best buzzword in the industry "El mercado habla de 'AI Harness' como si fuera magia. El verdadero arnés de un LLM es un Proxy Inverso y un Middleware Transaccional determinístico. Es el código tradicional (styrr-llm y sayay-guard) el que confina, audita y presupuesta la inferencia probabilística antes de que toque tu infraestructura en la nube." — TokenOps raw research, Turno 8 The Hook "Harness" is the most polarizing word in AI engineering right now. Depending on who you ask it's either the industry's worst buzzword or the best technical concept ever packaged badly. It's both — and the difference is whether you can name the actual engineering underneath. Why It's the WORST Buzzword (the smoke) It's a wrapper. 90% of the time, "we built an Enterprise AI Harness" means someone wrote a Python requests script or an Express server that wraps the OpenAI or Bedrock API. Language appropriation. "Harness" literally means arnés — a tether. Marketing sells it as "an intelligent structural armor that tames the wild energy of AI." In systems engineering it's a middleware, or a glorified try/catch with JSON schema validation. No standard. No rigorous CS definition exists, so anyone calls anything "harness" — a log interceptor, a proxy, a YAML config file — inflating expectations without delivering real value. Why It's the BEST Buzzword (the engineering) Strip the LinkedIn marketing and the original test harness metaphor becomes genuinely powerful for generative AI: electrical isolation of uncertainty. An LLM is a highly unstable, probabilistic component. You cannot wire it directly into a bank's production database. You need a physical code "harness" that isolates it. When the model goes crazy

Cloud spending is on track to pass a trillion dollars a year, and most of it is wasted. Industry data puts idle resources, over-provisioned instances, and missed commitment discounts at 25 to 35% of the average cloud bill. For an early-stage company where hosting can eat 6 to 12% of revenue, that waste is not a rounding error. It is runway. The good news is that cloud cost optimization rarely requires a painful re-architecture. The biggest wins come from a few low-risk moves: switching off what nobody is using, rightsizing what is over-provisioned, and buying commitments for the baseline you will run anyway. The discipline that ties these together is called FinOps, and you do not need a dedicated team to practise it. You need visibility into where the money goes, a short list of high-leverage actions, and the habit of reviewing the bill before it reviews you. This playbook walks through exactly that, in the order we apply it for the startups we work with. Find the waste before you cut it You cannot optimize what you cannot see. Before touching a single instance, make your spend legible. That starts with cost allocation tags, a small enforced set like env , team , service , and customer , applied to every resource. Untagged spend is where waste hides, so treat an untagged resource as a bug to be fixed, not a footnote. With tags in place, the native tools do most of the heavy lifting. AWS Cost Explorer (and its equivalents on GCP and Azure) will show you the trend line, the biggest line items, and the resources sitting idle. Set budget alerts at the account and per-environment level so a runaway job pings you on day two, not on the invoice. The most important shift is what you measure. Don't stop at "we spent $14k on EC2." Tie cost to a unit of business value: cost per customer, per active user, or per thousand requests. That single number turns an abstract bill into a metric you can defend in a board meeting and optimize against deliberately. The number that matters

For a decade the advice was simple: put everything in the cloud and never look back. In 2026 that consensus is cracking. A Barclays survey found 83% of enterprises plan to repatriate at least some workloads from public cloud to private infrastructure, and IDC puts the share expecting to move compute or storage within the year near 80%. The most-cited example is still 37signals, the team behind Basecamp, who left the public cloud and reported saving roughly $7 million over five years. It is tempting to read those numbers as "cloud was a mistake." It was not. The cloud is still the right home for spiky, unpredictable, early-stage workloads where you are buying speed and optionality. What changed is that a lot of companies have now run the same steady, predictable workload on rented hardware for years, paying a premium for flexibility they stopped using. Repatriation is not a reversal of cloud strategy. It is the correction that comes after the bill gets big enough to read carefully. The question worth answering is not "should we leave the cloud" but "which specific workloads no longer earn their cloud premium," and that is a question you can answer with numbers. What is actually driving the move Cost is the headline, and it is real. Organizations that repatriate the right workloads commonly report 30 to 60% lower infrastructure spend for those workloads, because on-demand cloud pricing carries a large convenience margin that only makes sense when your usage is genuinely variable. Run a database at a steady 60% utilization every day for three years and you are paying a premium for elasticity you never touch. But cost is not the only force. Just over half of organizations name data security and privacy as a top driver, and in Europe the regulatory pressure is sharper than the cost case. Frameworks like DORA are already enforceable, and regulators increasingly want evidence of control over where data physically lives, not just a contractual promise from a hyperscaler. Fo

You shut the VM down to save money, and next month it is still on the bill. This is one of the most common Azure billing surprises, and it comes down to a distinction Azure does not make obvious: there is a difference between a VM that is Stopped and one that is Stopped (deallocated) , and only one of them stops the compute charges. Here is exactly what is happening, and the cost that survives even when you do it right. Stopped vs Stopped (deallocated) Azure has two "off" states, and they bill completely differently. Stopped (from inside the OS). If you run shutdown inside the guest OS, the VM powers off but Azure keeps the compute resources allocated to it. The status shows Stopped . You are still paying full compute price for a VM doing nothing. This is the trap. Stopped (deallocated). If you stop the VM from the Azure Portal, CLI, or PowerShell, Azure deallocates it, releasing the underlying compute. The status shows Stopped (deallocated) , and compute billing stops. So the rule: shutting down from inside the guest does not save you money. You must deallocate, and deallocation only happens when you stop it through Azure, not through the OS. # This deallocates and stops compute billing: az vm deallocate --resource-group my-rg --name my-vm # Inside-the-OS "shutdown" does NOT deallocate. Status stays "Stopped", billing continues. Check which state you are actually in: az vm get-instance-view --resource-group my-rg --name my-vm \ --query "instanceView.statuses[?starts_with(code, 'PowerState')].displayStatus" -o tsv If that returns VM stopped you are still paying. If it returns VM deallocated you are not paying for compute. The disks nobody mentions Here is the part that catches people even after they deallocate correctly: deallocation stops compute billing, not storage billing. The managed disks attached to the VM (the OS disk and any data disks) keep costing money whether the VM is running, stopped, or deallocated. A deallocated VM with a 512 GB Premium SSD is still

Everybody's cloud cost journey has the same first chapter: someone writes a Lambda that stops the dev instances at night and starts them in the morning. It works. It saves real money. And then the environment grows, and one morning the script that ran fine for a year quietly causes an outage. The shutdown script that works on one instance breaks at three hundred, and it breaks in four specific ways. Here is each one, because knowing them is the difference between saving money and writing a postmortem. The script that works on one instance # stop_dev.py, EventBridge at 20:00 import boto3 ec2 = boto3 . client ( " ec2 " ) ids = [ i [ " InstanceId " ] for r in ec2 . describe_instances ( Filters = [{ " Name " : " tag:env " , " Values " :[ " dev " ]}])[ " Reservations " ] for i in r [ " Instances " ]] ec2 . stop_instances ( InstanceIds = ids ) At small scale this is fine. At scale, here is what goes wrong. Break 1: dependency order Your app instance depends on a database. Stop them in a random order and starting back up, the app comes alive before the database is ready and lands in a crash loop. On one box you get away with it. Across an environment with app tiers, databases, and caches, ordering is not optional: databases up before apps, apps up before the things that call them. A flat list of instance IDs has no concept of "start this after that." Real scheduling needs dependency-aware sequencing (storage, then compute, then application), with delays between tiers. Break 2: timezones The script fires at 20:00. Whose 20:00? As you add teams in different regions, a single UTC cron either shuts down someone's environment in the middle of their afternoon or leaves it running all night. At scale, schedules have to be timezone-aware per environment or per team, not one global time that is wrong for most of the world. Break 3: no overrides, so people disable it The night QA needs staging up late for a release, the script kills it at 20:00 anyway. This happens twice, and then s

CPU rightsizing is a solved, well-documented practice. GPU rightsizing is where the real money is now, and almost nobody writes about it, because GPU instances are expensive enough that people are scared to touch them and unsure how. Given how much a GPU box costs per hour, an over-provisioned one is the single most expensive rightsizing mistake in your account. Here is how to rightsize AWS GPU instances without breaking the workload, including the compatibility check that quietly bites people. Know what each GPU family is for Rightsizing starts with using the right family, not just the right size. On AWS: G5 / G6 (NVIDIA A10G / L4): inference, graphics, smaller training. The workhorses for serving models and lighter ML. Cheaper per hour. P4 / P5 (A100 / H100): large-scale training and heavy inference. The expensive tier, built for jobs that genuinely need the horsepower and interconnect. The most common GPU waste is running a training-class P-family instance for an inference workload that a G-family instance would serve fine at a fraction of the cost. Wrong family is a bigger error than wrong size. Rightsize on the binding resource, and it is usually not CPU GPU workloads have several resources that can be the bottleneck, and CPU utilization, the thing you would check for a normal instance, is often the least relevant: GPU utilization: is the GPU actually busy, or idle between requests? (CloudWatch does not report this by default; you need the CloudWatch agent with GPU metrics or nvidia-smi telemetry.) GPU memory: many inference workloads are GPU-memory-bound, not compute-bound. A model that fits in less VRAM can move to a smaller GPU. Host CPU and RAM: sometimes the GPU is fine but the instance is over-sized on host resources. The rightsizing signal is a GPU sitting at low utilization or using a fraction of its VRAM over a sustained window (a 90-day-style baseline, same idea as CPU rightsizing). That is your candidate to move down a size or across to a cheaper fam

LLM APIs like Claude feel snappy—until latency spikes hit your users. By caching prompt‑response pairs right at the edge, you can cut round‑trip time to milliseconds. This post shows you how to make that happen with CloudFront Functions and a Lambda origin. Why Prompt Caching Matters for LLM‑Powered Apps When a user types a question, your front‑end sends the text to an LLM (large language model) API, waits for the model to generate a reply, and then shows the answer. The user experience is dominated by two things: Network latency – the time it takes for the request to travel from the user’s browser to the API endpoint and back. Model compute time – how long the LLM needs to think. Even if the model itself is fast, the network hop to the provider’s data center can add 100 ms – 300 ms, and sometimes more during traffic spikes. For a chat UI that refreshes every few seconds, those extra milliseconds feel like a noticeable lag. Prompt caching means storing the exact prompt (the user’s message) together with the response (the model’s answer) in a fast lookup table. If the same prompt arrives again within a short window, you can return the cached answer instantly, without touching the LLM provider at all. In plain English: Think of the cache as a “sticky note” on the receptionist’s desk. If someone asks the same question twice, the receptionist can hand them the note instead of calling the manager again. Freshness vs. Speed LLM responses are not immutable—new data, temperature settings, or model updates can change the answer. A short time‑to‑live (TTL) of a few minutes gives you a good trade‑off: most users repeat recent prompts, but you still get new answers after a reasonable window. Setting Up a CloudFront Distribution with an Edge Key‑Value Store The big picture Edge KV store – a tiny key‑value database that lives on every CloudFront edge node. CloudFront Function – a lightweight JavaScript snippet (max 2 MB) that runs on every request before it reaches the origin. It

Google Cloud has introduced AI-powered Database Operations Agents, featuring an Onboarding Agent that streamlines database setup and an Observability Agent that helps automate troubleshooting, performance optimization, and tuning. Integrated with Gemini Cloud Assist, these agents support multiple database services, including AlloyDB, Bigtable, and Spanner. By Sergio De Simone

Every workflow builder I have used opens the same way: a blank canvas and a palette of nodes. Zapier, n8n, Make - all of them assume you already know what you want, already decomposed into steps, before the tool is any use to you. Most people don't. They know the chore . "I keep forgetting to check the weather before I bike in." The gap between knowing the chore and knowing the DAG is precisely the work these tools leave you to do alone, and I think it is why most people who try one never build a second automation. So I built Weaver, which inverts it. Weaver interviews you about the chore, one question at a time, until it actually understands the goal. Then it designs the workflow, validates it, deploys it, and runs it. The canvas is an output rather than an input. This post is about the parts that did not go to plan, because those are the parts worth reading. The interview is the whole product Three rules, and they are harder than they look: One question per turn. Never three bundled into a paragraph. Never invent a value the person has not given you. No quietly assumed recipient, city, or time. A correction updates one detail. Say "actually, Mondays" halfway through and it changes that and keeps going, instead of restarting the interview. That third one is the one people notice. Restarting an interview because the user corrected themselves is the single fastest way to make software feel like it is not listening. Only once it restates the whole task in plain language and you confirm does it save the intent and hand off to a separate Designer Agent. Two agents, deliberately not one The Conversation Agent and the Designer Agent are different models with different prompts and no shared state beyond a saved intent. That is a design decision, not an accident of implementation. Understanding a person and designing a system are different skills with different failure modes. Collapsing them into one prompt makes both worse: the interviewer starts proposing architecture hal

Cloudflare announced Wallets, giving agents a stablecoin balance and spending controls, though only handle claiming is live and squatting complaints have already surfaced. Payments run on x402, now hosted by the Linux Foundation. The controls bound single payments, not sequences, leaving composition to the application above. By Steef-Jan Wiggers

When I first looked at AWS, it felt unnecessarily complicated. EC2 runs something. S3 stores something. RDS manages something. Lambda does something “serverless.” I understood the definitions individually. But I still didn't understand AWS. The breakthrough comes when you stop learning these services separately and ask one simple question: How would I use EC2, S3, RDS and Lambda together to build one real application? That's when AWS starts making sense. So instead of another article explaining AWS services like dictionary definitions, let's build something. Imagine we're creating a simple job portal where users can create accounts, upload resumes and apply for jobs. Nothing extraordinary. But this small application is enough to understand some of the most important ideas in cloud architecture. First, Forget AWS for a Minute Before choosing any AWS service, think about what our application actually needs. Someone visits our website. They create an account. They upload their resume. They browse available jobs. They submit an application. When a resume is uploaded, perhaps we want to automatically process it and extract some basic information. Already, we can identify four different technical problems. We need somewhere to run our application. We need somewhere to store uploaded files. We need somewhere to store structured information such as users and applications. And we need something that can automatically react when certain events happen. Now AWS becomes easier. Because instead of memorizing services, we're matching problems to solutions. Our architecture starts with four pieces: EC2 → Application S3 → Files RDS → Structured Data Lambda → Event-Driven Processing Let's see what that actually means. EC2: Where Our Application Lives Our job portal needs backend code. Maybe we're building it using Python, Node.js, Java or another backend technology. That code needs somewhere to run. This is where Amazon EC2 enters the picture. Think of EC2 as renting a computer insid