DEV Community: Felipe L

Rust & Bevy Space Economy Sim: Self-Running AI Agent Demo

Felipe L — Wed, 22 Jul 2026 14:55:16 +0000

What Happened

Space Project Sim, an open‑source Rust project on GitHub, launches a fully autonomous space economy simulation built with the Bevy engine. Ships, colonies, and markets run without human input, driven by AI agents that choose actions based on resources, trade routes, and politics. The simulator demonstrates how Rust’s speed and Bevy’s ECS can power a self‑running model.

The code is modular and event‑driven. Adding new agents or rules requires minimal changes. The simulation runs continuously, emitting data streams that external services can consume or that can be visualized in real time.

Why This Matters for Builders

Event‑driven architecture: The simulator uses an event bus to trigger agent actions, mirroring n8n’s decoupled triggers and actions. This makes it easy to plug in new steps or services.
Performance & scalability: Rust’s zero‑cost abstractions allow thousands of entities to run concurrently. Builders can adopt similar patterns to keep AI‑agent pipelines responsive under heavy load.
Modular agent design: Each agent is a small, self‑contained module. Teams can swap or upgrade components without rewriting entire workflows.
Observability: The project logs detailed events and state changes. Monitoring these logs helps detect anomalies early in AI‑driven processes.
Open‑source learning: Examining the codebase teaches how to structure complex simulations, manage concurrency, and expose APIs for external consumption—skills directly transferable to building AI‑agent services.

FAQ

Q: Can I use Rust for my AI‑agent workflows?

A: Yes. Rust’s safety and performance make it a solid choice for backend services that need to handle many concurrent agents or heavy computation.

Q: How does the event system compare to n8n’s triggers?

A: The simulator’s event bus behaves like n8n’s trigger nodes, propagating events to subscribed agents. Replicate this pattern in n8n with webhook triggers or custom plugins.

Q: Is the code ready for production use?

A: The project is a demonstration. Its modular design and extensive logging provide a good foundation for production‑grade systems once hardened and tested.

Originally published on Automations Cookbook.

Mona Lisa Drawn by GPT‑5.6, Claude, Gemini, and Grok

Felipe L — Wed, 22 Jul 2026 14:55:06 +0000

What Happened

GPT‑5.6, Claude, Gemini, and Grok each produced a high‑resolution PNG of the Mona Lisa from the prompt: “draw the Mona Lisa with colored pencils.” The images match the original’s shading and composition. Side‑by‑side comparisons show similar quality across the four models, with only slight style variations.

The demo proves mainstream LLMs can generate coherent images from text without fine‑tuning. Diffusion or transformer‑based decoders are now reliable enough for production.

Why This Matters for Builders

Design tasks that used to route through an external tool or designer can now happen inline in the workflow instead.
Workflows can embed user‑specific graphics—avatars, charts, or mock‑ups—directly into emails, dashboards, or chat.
Prototypes appear faster; teams hand off only polished assets to designers.
Batch requests and caching cut API costs, especially when images are charged per call.
Integrated moderation layers can filter copyrighted or disallowed content before delivery.
Multiple providers give fallback options and the ability to combine outputs for higher quality or SLA compliance.

FAQ

Q: Can I embed these image generation calls directly into an n8n workflow?

A: Yes. Each provider offers an HTTP API that n8n’s HTTP Request node can call. Pass the prompt, receive the image URL or binary data, and forward it to downstream nodes like email or Slack.

Q: Do I need to fine‑tune the models for my domain?

A: Out‑of‑the‑box performance usually suffices. For brand consistency, try prompt engineering or a provider’s fine‑tuning service.

Q: How do I handle large image payloads in my automation?

A: Store the image in a cloud bucket (S3, GCS, Azure Blob) and pass the URL to downstream steps. This keeps the workflow lightweight and avoids size limits on intermediate nodes.

Originally published on Automations Cookbook.

LangGraph vs. CrewAI vs. Microsoft Agent Framework vs. n8n

Felipe L — Wed, 22 Jul 2026 13:25:16 +0000

The short answer

Pick LangGraph when you need to control exactly how an agent moves between steps and retries. Pick CrewAI when you're modeling a team of specialist agents with clear roles and want that structure to stay readable. Pick Microsoft Agent Framework when your org already lives in the Microsoft/Azure stack and needs one supported SDK across Python, C#, and Java. Pick n8n when the people building and maintaining the workflow aren't primarily software engineers, or when the agent needs to sit next to 400 other business integrations you already run.

None of these are mutually exclusive. A common production pattern we see in the Automations Cookbook recipes is n8n orchestrating the business trigger (a webhook, a form, a schedule) and calling out to a LangGraph or CrewAI service for the part that actually needs multi-step reasoning.

What each one is actually for

LangGraph — state machines for agents

LangGraph models an agent as an explicit graph: nodes are steps, edges are transitions, and state is a typed object that flows between them. That gives you two things frameworks with more implicit control loops don't: you can pause, inspect, and resume execution at any node, and you can enforce that certain transitions never happen. Teams building on LangGraph tend to be doing so because they've already hit the wall with a simpler "just call the LLM in a loop" approach and needed real control over branching and retries.

CrewAI — role-based multi-agent teams

CrewAI's core abstraction is the crew: a set of agents, each with a role, a goal, and a backstory, working through a sequence of tasks. It reads closer to an org chart than a state machine, which makes it the easier framework to hand to a teammate who isn't deep in the codebase — the config genuinely describes what the system does. CrewAI has grown fast enough to become one of the most-starred agent frameworks on GitHub, and it now ships an enterprise tier aimed at teams that outgrew the open-source crew definition files.

Microsoft Agent Framework — the AutoGen successor

If you built on AutoGen, this is where that investment goes now. Microsoft merged AutoGen with Semantic Kernel into a single Microsoft Agent Framework in October 2025, and AutoGen itself is in maintenance mode — new projects shouldn't start on it. The pitch for Agent Framework is consistency: the same agent orchestration concepts across Python, C#, and Java SDKs, wired into Azure AI Foundry and the rest of the Microsoft enterprise stack. It's the pragmatic default if procurement, security review, and long-term support already point you at Microsoft.

n8n — the no-code layer that talks to all of them

n8n isn't trying to be an agent-reasoning framework — it's trying to be the workflow layer that triggers, sequences, and connects everything else, including calls out to LangGraph or CrewAI services. Its advantage is breadth: hundreds of pre-built integrations (Slack, HubSpot, Google Sheets, Stripe) that would otherwise be custom code in a pure-code agent stack. For teams where the actual agent logic is simple (classify, summarize, route) but the surrounding business process touches a dozen SaaS tools, n8n is usually the faster path to production — see the AI Workflow Automation guide for patterns.

How to actually decide

Ask who maintains this after you ship it. If it's an ops or RevOps person, not an engineer, n8n's visual workflow wins even if it's less flexible. If it's an engineering team that needs fine-grained control over agent state and retries, LangGraph earns its complexity. If the mental model is "a team of specialists with different jobs," CrewAI keeps that structure honest as the system grows. If your organization already has Microsoft/Azure procurement, security, and support relationships in place, Agent Framework removes a category of approval friction the others don't.

FAQ

Q: Is AutoGen still worth learning in 2026?
A: Only if you're maintaining an existing AutoGen system. Microsoft has moved new development to Agent Framework, and AutoGen is in maintenance mode.

Q: Can I use n8n and LangGraph together?
A: Yes — it's a common pattern. n8n handles triggers, integrations, and the surrounding business workflow; a LangGraph service handles the part of the task that needs stateful multi-step reasoning, called from an n8n HTTP Request node.

Q: Which of these is easiest for a non-engineer to maintain?
A: n8n, by a wide margin — its visual editor is built for that. CrewAI's role/task config is the next easiest to read without a deep coding background.

Originally published on Automations Cookbook.

Claude Code's Usage Meter Quietly Got 5x Stricter — What Builders Should Do

Felipe L — Wed, 22 Jul 2026 13:25:05 +0000

What happened

A developer running Claude Code for "review loops, long running agent jobs, local automation runs" started tracking his own token logs after noticing his weekly quota emptied faster than usual. The numbers he published are specific: in a comparable week of work, visible Opus input/output tokens dropped to 1,442,423 — down from 8,927,831 and 8,477,395 in two previous heavy weeks. That's roughly 16-17% of the old volume for what he describes as the same kind of work, on the same machine, at the same subscription price.

Widen the count to include cache-creation tokens (not cache reads, just the cost of writing to cache) and the ratio holds: about 20% of the old volume. Either way, the effective cost of a unit of useful work looks close to 5x higher than before, with no announced price change from Anthropic.

The stranger detail: a fresh account created on June 29 went from roughly full quota (100% on both the 5-hour and 7-day meters) down to 65%/84% over about nine hours — with zero visible Opus rows logged locally during that window. The local usage log and the account's internal meter disagree, and there's no published explanation for why.

Why this matters for automation builders

If you're running Claude Code — or any hosted coding agent — inside a production workflow (CI review bots, scheduled refactor jobs, agent-driven ticket triage), this is a concrete operational risk, not just a pricing gripe:

Your cost model can shift under you with no changelog entry. A workflow that ran comfortably inside a monthly quota last month can silently blow through it this month, with the same code doing the same job.
Client-side usage logs and provider-side meters can disagree. If you bill clients or track internal cost-per-workflow based on your own token counts, you may be underestimating what the provider is actually charging you for.
Single-provider agent stacks are exposed to this by default. Any automation that hard-codes one model provider inherits that provider's metering behavior, pricing changes, and outages with zero negotiating room.

None of this means Claude Code is unusable — it means the same discipline that applies to any metered cloud dependency (rate limits, egress costs, API pricing tiers) now applies to LLM-powered automation too.

What to do about it

Three concrete moves, in order of effort:

Log your own token usage outside the provider's dashboard. Every agent framework and most SDKs expose token counts per call. Write them to a database or even a flat file per run, so you have an independent record to compare against your bill.
Design workflows so the model is swappable, not hard-coded. If your n8n or agent pipeline calls one provider directly inside business logic, a pricing or quota shock forces an emergency rewrite. Routing model calls through a single node/function makes swapping providers a config change instead of a fire drill.
Keep a cheaper fallback model wired in for non-critical steps. Not every step in an agent workflow needs your most expensive model. Summarization, classification, and routing steps are often good candidates for a cheaper or open-weight model, reserving the expensive one for the step that actually needs it.

FAQ

Did Anthropic officially confirm a price increase for Claude Code?
No. The developer's post is based on his own local token logs, not an announcement from Anthropic. The post explicitly asks Anthropic for a detailed usage ledger (timestamp, model, tokens, meter deltas) rather than claiming certainty about the cause.

Is this specific to Opus, or does it affect other Claude models too?
The published data is specifically about visible Opus input/output token counts inside Claude Code. The post doesn't report comparable data for other models in the Claude line.

What's the fastest way to reduce exposure to this kind of risk?
Abstract the model call behind one interface in your workflow (a single n8n node or a thin wrapper function) so switching providers, or splitting expensive steps from cheap ones, doesn't require touching the rest of the automation.

Originally published on Automations Cookbook.

How to Build Your First Production AI Agent with n8n

Felipe L — Wed, 22 Jul 2026 13:24:55 +0000

The shape of a real n8n agent

Most tutorials show an agent as one node: trigger goes in, magic AI node does everything, result comes out. Production systems don't look like that. They look like five distinct pieces:

Trigger — a webhook, form submission, schedule, or inbound email.
Retrieval (optional) — pull the context the model needs: a CRM record, a support ticket history, a row from Google Sheets.
Reasoning step — the LLM call that decides what to do, given the trigger and retrieved context.
Tool call(s) — the action the agent decided on: send a Slack message, update a CRM field, create a calendar event.
Human-in-the-loop checkpoint — a pause before anything that can't be undone (sending an email to a customer, charging a card, deleting a record).

Skip step 5 and you don't have an agent, you have an unsupervised script with an LLM inside it. The Resilience Engineering playbook in our Agent Dev hub covers what happens when that script hits a rate limit or a malformed response at 2am with nobody watching — worth reading before you flip a workflow from "test" to "active."

Walking through a real example

Take a lead-qualification agent: a form submission comes in (trigger), the workflow looks up the company domain against a firmographic API (retrieval), an LLM node reads the form answers plus firmographic data and decides whether this is a qualified lead and what tier (reasoning), then either creates a CRM record and Slack-notifies the sales rep (tool call) or — if the model's confidence is low — routes to a human for manual review instead of auto-qualifying (the checkpoint). That's the same five-piece shape as the n8n + HubSpot lead-response recipe in the cookbook, just described in agent terms instead of "automation" terms.

Where teams get this wrong

No retrieval step at all. Feeding the LLM only the trigger payload and asking it to "decide" produces plausible-sounding but ungrounded output — the model doesn't know your CRM's actual lead-scoring rules unless you put them in front of it.

No confidence threshold. Treating every LLM output as final means every hallucination reaches a customer or a system of record. Add an explicit low-confidence branch, even a crude one (a keyword check, a second cheaper model call, a simple score threshold), before the model's decision becomes an irreversible action.

One giant prompt instead of a workflow. If your "agent" is a single prompt trying to retrieve, decide, and act all at once, you've hidden the five-piece shape inside prose instead of making it inspectable as separate nodes. That's harder to debug when it breaks, and it will break.

FAQ

Q: Do I need a vector database for this, or is Google Sheets retrieval enough?
A: Depends on what you're retrieving. Structured lookups (a CRM record, a spreadsheet row) don't need a vector database at all — a plain API call or Sheets read is faster and easier to debug. Save vector search for genuinely unstructured content like support tickets or documentation.

Q: What counts as "irreversible" for the human-in-the-loop checkpoint?
A: Anything that leaves your system once it runs: outbound emails, payments, record deletions, and any action a customer directly sees. Internal draft creation or CRM tagging is usually safe to automate without a checkpoint.

Q: Can this same five-piece shape work outside n8n?
A: Yes — it's the same shape LangGraph or CrewAI would give you, just expressed as code instead of a visual workflow. See our framework comparison for when code-first is worth the extra setup.

Originally published on Automations Cookbook.

AutoGen Is in Maintenance Mode — Migrating to Agent Framework

Felipe L — Wed, 22 Jul 2026 13:24:44 +0000

What happened

Microsoft folded AutoGen — its research-driven multi-agent conversation framework — into Semantic Kernel, its enterprise agent SDK, and shipped the result as a single Microsoft Agent Framework in October 2025. AutoGen is now in maintenance mode: it still gets security patches, but new features and new projects are directed to Agent Framework instead.

This isn't a rename. AutoGen and Semantic Kernel had genuinely different design centers — AutoGen optimized for flexible, research-friendly multi-agent conversations; Semantic Kernel optimized for enterprise SDK consistency across Python, C#, and Java, with tighter Azure integration. Agent Framework is Microsoft's attempt to keep AutoGen's conversation patterns while giving them Semantic Kernel's production and governance story.

Why this matters if you're building agents now

If you're starting a new project today, start on Agent Framework, not AutoGen — you'd otherwise be building on a track Microsoft has already said is winding down. If you have an existing AutoGen system in production, you don't need to panic-migrate; maintenance mode means it keeps working and keeps getting patched. But budget the migration as planned technical debt rather than something to revisit "eventually" — the gap between AutoGen and current tooling only grows.

The practical risk isn't that AutoGen stops working overnight. It's that the ecosystem — tutorials, community answers, third-party integrations — increasingly assumes Agent Framework, which makes debugging an aging AutoGen system slower every quarter you wait.

What to actually check before migrating

Multi-agent conversation patterns: AutoGen's group-chat and nested-conversation patterns have Agent Framework equivalents, but the API surface is different enough that this isn't a find-and-replace job — plan to re-test conversation flows, not just re-import.
Azure dependencies: if you're already deep in Azure AI Foundry, Agent Framework's tighter integration is a net win, not just a migration cost.
Language spread: if your team ships agents in more than one of Python/C#/Java, Agent Framework's whole pitch is consistency across those — evaluate whether that consistency is worth the migration effort for your specific stack.
Third-party tool integrations: audit which AutoGen-specific plugins or tool-calling patterns you depend on before assuming they carry over unchanged.

If your agent logic is simple enough that it's really just an LLM call wrapped in retry logic — no multi-agent conversation, no complex state — it may be cheaper to rebuild that piece directly than to migrate a heavier framework's worth of scaffolding for it. That's a case where moving the logic into an n8n workflow that calls the model directly can be simpler than carrying framework-specific abstractions forward at all.

FAQ

Q: Do I have to migrate off AutoGen immediately?
A: No. Maintenance mode means it keeps receiving security patches. Migrate on your own timeline, but don't start new projects on it.

Q: Does Agent Framework replace Semantic Kernel too?
A: Yes — it's the merger of both AutoGen and Semantic Kernel into one framework, so Semantic Kernel projects are also moving toward it over time.

Q: Is the migration mostly automated, or a rewrite?
A: Expect a partial rewrite. Core concepts carry over, but the API surface differs enough that conversation flows and tool integrations need re-testing, not just re-importing.

Originally published on Automations Cookbook.