DEV Community: Reno Lu

loopy: packaging agent work as bounded, checkable loops instead of one-shot prompts

Reno Lu — Mon, 13 Jul 2026 15:38:39 +0000

Most prompts ask an agent to do a thing once. The insight behind Forward-Future/loopy is that the work worth automating is rarely one-shot, so the unit it packages is not a prompt but a loop: a short playbook with a built-in check, a next step, and an explicit rule for when to stop.

The distinction it draws

The README makes its case with a single before-and-after. A one-shot prompt says "Make this website faster." A loop says: find the slowest page, make one focused improvement, measure it again, keep the change only if it helps, and repeat until every page meets the target or another pass stops helping. Same goal, but the second version tells the agent how to judge its own result and when to quit.

A good loop, by the project's own framing, answers four questions: what the agent is trying to accomplish, how it will know whether the latest attempt worked, what it should do with what it learned, and when to finish or ask for help. That last question gets unusual emphasis. The README is blunt that loops "are not permission for an agent to run forever," and that the best ones are deliberately bounded, with a real check and a moment to hand control back to a person when judgment or approval is needed.

Two parts, only one of which you install

loopy is really two things in one repository, and the README works hard to keep them separate. The first is the Loop Library website, a public catalog where people and agents browse published loops and copy their prompts, with no installation required. The second is Loopy itself, an optional installable skill that guides an agent through working with those loops. As the README puts it, the website is the library and Loopy is a companion way to work with it. You can hand an agent the website without ever installing the skill.

For agents that do not have the skill, the project exposes the catalog directly: a published agent guide, an llms.txt instruction file, and both JSON and plain-text versions of the catalog. That is a practical touch. It treats "an agent reading this without our tooling" as a first-class case rather than an afterthought.

What the skill actually does

Installed, Loopy covers nine paths. Discover inspects a codebase or coding-thread history for repeated work and turns the strongest candidate into a bounded loop. Find searches the live catalog and recommends up to three published loops without running them. Loop Doctor audits a loop and repairs only the material problems. Adapt tailors a loop to your real tools and limits. Craft interviews you one question at a time and builds a loop when the catalog has no good fit. Run executes a loop in bounded passes and returns an evidence-backed receipt. Debrief reviews completed run receipts. Save appends a loop to a project's LOOPS.md. Publish prepares a preview and submits only after you approve the exact text.

Two design choices stand out. Discovery refuses to call work "repeated" until it sees at least two distinct thread occurrences; a code pattern with no run history is labeled a potential loop, not proven recurrence. And LOOPS.md is treated as untrusted reference data, so a saved prompt does not by itself grant permission to run code, deploy, schedule, or send messages. If an accepted prompt contains secrets, Loopy refuses to save it until you supply a sanitized version.

Where it fits

The README states that Loopy checks the live catalog when recommending a loop, and that it does not quietly start schedules, change production, publish content, or send messages on your behalf. Those claims are the authors' own, not something the README verifies, but they read as a coherent posture rather than marketing: the tool wants to be the thing that proposes bounded, checkable workflows and then gets out of the way.

Installation is a single npx skills add Forward-Future/loopy command with per-agent flags for Codex, Cursor, and Claude Code. The repository is MIT licensed. What it does not include, at least in the portion of the README available here, is any benchmark or evidence that agents following these loops converge faster or produce better results than open-ended prompting. The argument is structural and stated plainly, which is refreshing, but it remains an argument rather than a measured result. For teams already running agents against recurring maintenance work, the loop framing and the nine named paths are worth a look on their own terms.

GitHub: https://github.com/Forward-Future/loopy

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

What AI Code Assistants Get Wrong About Security

Reno Lu — Mon, 13 Jul 2026 13:57:36 +0000

The research is uncomfortable reading

When NYU researchers tested GitHub Copilot across 89 security-relevant scenarios in 2021, roughly 40% of the generated programs contained a vulnerability. That wasn't a one-off tied to an early model. Veracode's 2025 GenAI Code Security Report evaluated output from over 100 large language models and found about 45% of AI-generated samples contained a security flaw—including OWASP Top 10 issues—with newer, larger models showing no meaningful improvement.

The structural reason matters for how you respond to it. These models are trained to predict plausible code from enormous public corpora, and public code is full of insecure patterns. Without explicit security guidance in the prompt, the default output reflects the average of its training data. That average is not secure.

The failure modes are not exotic. They map almost directly onto the categories that drive traditional code review: SQL injection from string-concatenated queries, command injection, XSS from unescaped output, hardcoded secrets, weak or deprecated cryptography, missing access-control checks, path traversal. The OWASP Top 10 that experienced reviewers already know covers most of what AI assistants get wrong.

The trust gap is as dangerous as the code itself

Stanford's 2022–2023 study found that developers with AI assistant access wrote significantly less secure code than developers without it—and were more confident their code was secure. That pairing is worth sitting with: more trust, worse outcomes.

AI output is fluent, well-formatted, and confidently presented. It reads like a senior engineer wrote it. Reviewers unconsciously apply less scrutiny to code with that register, and automation bias leads engineers to defer to the machine, especially in technologies they're less familiar with—precisely where they're least equipped to catch a subtle flaw. The assistant has no accountability, no threat awareness, and no understanding of your specific deployment environment.

A distinctly AI risk: hallucinated packages

Package hallucination is worth calling out separately because it's specifically an AI problem, not a traditional code quality problem. A 2024 study generated over 205,000 unique hallucinated package names across 16 models. Around 20% of open-source model suggestions—and roughly 5% of commercial model suggestions—pointed to packages that didn't exist.

This creates a supply-chain attack called slopsquatting. An attacker registers a commonly hallucinated package name—names that models invent consistently, not randomly—with malicious code inside. Developers, or AI agents running autonomously, install it on the model's recommendation. The researchers registered one such name and observed thousands of downloads within months.

Every suggested dependency needs verification: does it exist, does it come from the expected maintainer, and is it pinned to a known-good version before it enters a lockfile?

Controls that match the actual risk

The right framing is to treat AI-generated code as untrusted input that happens to be useful—applying the same validation, review, and testing you'd demand of any external contribution.

Automate the predictable catches. Static analysis (Semgrep, CodeQL, Bandit depending on stack), secret scanners, and software composition analysis should run in CI on every AI-assisted change. These tools catch the injection patterns, exposed credentials, and known-vulnerable dependencies that appear most often. They're not new practice—they're existing practice applied with more urgency because assistant-driven volume increases the absolute number of defects entering a codebase.

Keep meaningful human review in the path. A reviewer rubber-stamping fluent code is not a control. The reviewer needs to understand the code, not just read it. Treat assistant output as a draft from an enthusiastic but unaccountable junior contributor: your name goes on the merge, not the model's.

Steer the assistant toward safer patterns. Security context in the prompt—asking for parameterized queries, explicit input validation, least-privilege handling—shifts output toward safer defaults. System instructions for AI coding tools can encode these requirements consistently rather than leaving them to per-session discipline.

A checklist for pre-merge review

Input handling

Parameterize all queries; no string-concatenated SQL
Avoid passing user input to the shell; use argument arrays when unavoidable
Escape output before rendering to HTML
Reject path traversal patterns; constrain file access to allowed directories

Auth and access control

Every new endpoint enforces authentication, not just the happy path
Object-level authorization checked per resource, not only at the route
No stubbed-out auth with TODOs or permissive defaults

Secrets and configuration

No hardcoded credentials—assistants frequently invent them as placeholders
Secrets sourced from environment variables or a secret store
Debug mode off and TLS verification on in production configuration

Dependencies

Verify suggested packages exist and come from the expected maintainer
Pin new dependencies to a specific version and run SCA scan before merge

Cryptography and sensitive data

No MD5 or SHA-1 for passwords, no ECB mode, no hand-rolled crypto
PII and secrets absent from logs and outbound API calls

Error handling

Errors don't expose stack traces, queries, or internal state to end users
Code fails closed on unexpected states, not open

The gap between code that looks right and code that holds up under pressure is where most AI-assisted security debt accumulates. These controls don't eliminate that gap, but they address the failure modes that research shows appear most often—and that's where the leverage is.

This guide originally appeared on agentpalisade.com. Agent Palisade helps small and mid-sized businesses put AI to work inside the tools they already use — practical automation, internal assistants, and AI security reviews. Book a free 30-minute call.

TestSprite's CLI hands your coding agent one clean failure at a time

Reno Lu — Sun, 12 Jul 2026 14:23:09 +0000

TestSprite's CLI makes a design choice most testing tools would never advertise: it refuses to do something. When a coding agent asks for a failure report, testsprite test failure get returns exactly one bundle tied to a single snapshotId, and the tool will not stitch data from two different runs together. The README calls the alternative a "frankenstein context," and avoiding it is the whole point.

The problem it targets

The pitch is narrow and specific: AI writes code in minutes, but verifying that code hasn't caught up. testsprite opens your live app, uses it like a real user, and hands your coding agent a description of what broke so the agent can fix its own work before the bug reaches you. This repo, testsprite-cli, is the official CLI for the TestSprite platform, which the README says 100,000+ teams use to test frontend and backend in the cloud against the running product rather than mocks.

The README leads with one external claim worth flagging as a claim: on the Codercup leaderboard, it says, the cheapest model in the field shipped the most correct app at 89%, at half the cost of the priciest, with this CLI in the loop. That is the repo's headline evidence for "verification beats model size." Take it as the authors' framing, not an independent result.

The loop, not the one-shot

The interesting part is the shape of the workflow, because it is built for an agent to drive, not a human to read. The README walks through a three-command session:

testsprite test create describes a behavior, runs it, waits, and exits 1 when the run fails.
testsprite test failure get pulls one self-contained bundle: the failing step, its neighbors, screenshots, DOM snapshots, the test source, a root-cause hypothesis, and a recommended fix target.
testsprite test rerun replays after the agent edits the code, exiting 0 on pass.

Every pass is banked into a durable suite instead of thrown away. The output is agent-shaped by construction: a stable --output json contract, predictable exit codes, and a --dry-run that exercises the full code path offline with canned data. That last flag matters for anyone who wants to learn the command surface without spending API calls or touching a live app.

Onboarding is one command, on purpose

testsprite setup prompts for an API key, verifies it, and installs a verification-loop skill for whatever coding agent you use. The README lists claude, cursor, cline, windsurf, antigravity, and codex, with a separate agent install command covering kiro and copilot as well. The idea is that you point Claude Code or Cursor at TestSprite, have it run setup, and the agent then knows how to create, run, and triage tests on its own rather than guessing from the README. There is a non-interactive path too, TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude, for CI and onboarding scripts.

The command table is broad for a project created in June 2026: read commands (project list, test steps, test failure summary), write commands (test create-batch, test code put with etag guarding, test plan put), and run commands (test run --all in wave order, test wait on a runId). Older names like init and auth configure survive as deprecated aliases that print a notice, so existing scripts keep working.

What to keep in mind

The CLI is Apache-2.0 and written in TypeScript, requiring Node 20.19+, 22.13+, or 24+. It is a client for a paid cloud platform, so the CLI alone does nothing without an API key, and the "tests against the live product in the cloud" model means your app has to be reachable. The README is thin on pricing, self-hosting, and what the failure bundle looks like on disk. For an agent-first testing loop, though, the core bet is clear: give the model one clean, self-consistent view of a failure, and let it close the loop itself.

GitHub: https://github.com/TestSprite/testsprite-cli

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Building an Internal AI Knowledge Assistant Your Team Can Actually Trust

Reno Lu — Sun, 12 Jul 2026 12:48:57 +0000

Many teams have experimented with generic chatbots only to watch them confidently answer questions with information they were never given. A knowledge assistant built on retrieval-augmented generation (RAG) takes a different approach: it answers only from documents you've explicitly approved, and it cites every claim it makes. That constraint is what separates a tool people rely on from one they quietly stop using.

How the Retrieval Pipeline Works

Understanding the architecture prevents the most common deployment mistakes.

Ingestion is where documents enter the system. Each file gets split into chunks, converted into vector embeddings (numerical representations of semantic meaning), and stored in a searchable index. The cleanliness of that index shapes every future answer—duplicates, drafts, and outdated files all compete for top retrieval slots and degrade output quality just as reliably as a bad model would.

Retrieval happens at question time. The system embeds the user's query and surfaces the semantically closest passages from the index. The model never sees your full document library—only the retrieved excerpts it was handed.

Generation is where the model writes an answer based solely on those retrieved passages. This grounding constraint is what makes the system trustworthy. A rule worth internalizing early: answer quality depends far more on retrieval precision than on which language model sits at the end of the pipeline.

Grounding, Citations, and Measuring Quality

Requiring the assistant to cite specific document sections for every claim isn't optional polish—it's the mechanism that makes hallucinations visible. If the model can't link a statement to a retrievable source, that statement shouldn't appear in the answer. Instruct the system explicitly to respond with something like "that information isn't in my approved sources" rather than drawing on general training data to fill coverage gaps.

Trust is something you measure, not assume. Maintain a curated test set of real questions with known correct answers, and run those tests on a regular schedule to verify that retrieval and grounding are holding up. Log actual user queries and review failed or flagged answers—that log is the highest-signal diagnostic you have for weak spots in your content, and it costs almost nothing to collect.

Access Controls Are Foundational, Not a Follow-On

The most consequential mistake in deploying an internal knowledge assistant is building a system that retrieves from documents the person asking isn't authorized to see. When HR policies, financial projections, legal files, and board materials share a single index, a question from any employee can surface content far above their access level—and without audit logging, no one will know it happened.

Filter retrieval by user role or group permissions, and separate genuinely sensitive content into access-gated indexes before ingestion begins. Define the boundary of what belongs in the index deliberately, because excluding content at the outset is far simpler than securing or removing it after the fact. If you're using a third-party vendor, get written confirmation that they neither retain your content nor use it to train future models. Organizations handling regulated or highly sensitive material should evaluate private or self-hosted deployment rather than treating it as an advanced configuration.

Maintain audit logs of queries and the sources returned. Those logs serve both compliance and diagnostics.

Starting Narrow, Expanding Deliberately

Broad initial rollouts of internal assistants tend to fail the same way: too many content domains, inconsistent document quality, no clear ownership, and users who conclude early that the system can't be relied upon. A narrow first deployment—one focused topic area, a well-maintained and current document set, a small group of early users who understand what they're evaluating—builds a foundation worth expanding from.

Before launch, set clear expectations: the assistant answers from approved sources, cites them, and acknowledges when its knowledge base doesn't cover a question. Assign a knowledge base owner who controls what gets ingested, maintains the review and update workflow, and removes outdated content promptly. Stale documents aren't inert—they compete with accurate content and get cited as authoritative.

Build a one-click mechanism for users to flag wrong or unhelpful answers, and treat that queue as a working priority. User flags surface content failures faster than any automated metric.

Only expand to additional content domains after the first has earned consistent, unprompted trust from its users. A single domain that people actually rely on delivers more organizational value than a sprawling system they've learned to treat with skepticism.

Loop Engineering: Score the System That Prompts Your Agents

Reno Lu — Sat, 11 Jul 2026 14:18:35 +0000

Loop Engineering makes a blunt argument: the person who writes prompts to a coding agent is now the bottleneck, so the job is to design the system that prompts the agent instead. The repo, cobusgreyling/loop-engineering, turns that claim into something you can measure. Run npx @cobusgreyling/loop-init . and it scaffolds skills, state, and budget files, then prints a "Loop Ready" score and your first loop command. The pitch on the tin is equally direct: stop prompting, design the loop, get a score.

The thesis has receipts

The README does not lean on its own authority. It quotes Peter Steinberger ("You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents") and Boris Cherny, Head of Claude Code at Anthropic ("I don't prompt Claude anymore. I have loops running that prompt Claude... My job is to write loops"). The framing that follows is the useful part: the leverage point has moved from crafting individual prompts to designing the control systems that orchestrate agents over time.

Loop Engineering breaks that control system into five building blocks plus memory. Automations and scheduling handle discovery and triage on a cadence. Worktrees give safe parallel execution. Skills hold persistent project knowledge. Plugins and connectors reach into real tools through MCP. Sub-agents split the work into a maker and a checker. Memory and state sit outside any single conversation as the durable spine. That list is opinionated, and it reads like the parts list for the animated loop the README diagrams: schedule, triage skill, read and write state, isolated worktree, implementer sub-agent, verifier sub-agent, then a human gate that either commits or escalates with full context.

Tools that turn the idea into a checklist

What separates this from a manifesto is the CLI surface. The repo ships a cluster of npm packages, each doing one small job. loop-audit computes a Loop Readiness Score and can suggest fixes or emit a badge for your README. loop-init scaffolds a starter with a budget and run log. loop-cost estimates token spend for a given pattern and cadence before you commit to it. loop-sync detects drift between STATE.md and LOOP.md. loop-context manages stateful memory and adds a circuit breaker for long runs. loop-mcp-server exposes patterns, skills, and state over MCP. loop-worktree manages isolated git worktrees per fix attempt. The tools publish to npm from tagged releases, so no clone is required to try them.

The patterns section is where the token-cost honesty shows. Seven production patterns come with a cadence and a cost rating. Daily Triage runs on a one-day-to-two-hour cadence and is cheap. PR Babysitter runs every five to fifteen minutes and is flagged High. CI Sweeper, at the same cadence, is Very High. Dependency Sweeper, Changelog Drafter, Post-Merge Cleanup, and Issue Triage round out the set, mostly at Low cost. Putting "Very high" next to a pattern in the same table that sells you on it is a small act of restraint worth noting.

The rollout advice matches. The README pushes a phased path: L1 report only, then L2 assisted fixes, then L3 unattended. The Grok example even spells it out ("Run loop-triage. Update STATE.md. No auto-fix in week one"). This is a project telling you to start by watching before you let anything write.

Who it targets, and what to check

Loop Engineering aims at developers using Grok, Claude Code, Codex, Cursor, and Opencode, with a cross-tool primitives matrix meant to map loop concepts across those agents. The repo also dogfoods: it runs its own validate-patterns and audit workflows on every push and pull request, and ships a LOOP.md describing the loops that maintain it.

The README is heavy on links out to docs, starters, and a live interactive picker, so some of the depth lives outside the page itself. The concepts here are also young, and the core idea of handing scheduled, semi-autonomous loops write access to your repo carries real risk, which is exactly why the L1-first, human-gate framing matters. If you have been wiring up cron jobs and sub-agents by hand, this repo is a structured vocabulary and a scorecard for work you may already be improvising.

GitHub: https://github.com/cobusgreyling/loop-engineering

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Where AI Automation Actually Pays Off in a Small Business

Reno Lu — Sat, 11 Jul 2026 12:47:48 +0000

Most automation conversations at small businesses follow a predictable arc: someone demos a tool, leadership gets enthusiastic, the team picks a process that sounds impressive rather than one that is genuinely suitable, and six months later the whole thing quietly gets shelved.

The fix is not better technology. It is better target selection.

How to Identify a Workflow Worth Automating

Before touching a platform or writing any code, the question is whether the task actually qualifies. Four signals matter:

Repetition over sophistication. A tedious task that runs hundreds of times per week will produce more measurable return than a complex one that happens twice a month. Cumulative time savings only add up if the volume is there.

Rule-based structure. If you could hand off the process to a capable new employee using a clear written checklist—no institutional knowledge required—it is likely automatable. Work that demands judgment, political context, or relationship awareness is harder terrain.

Predictable inputs. AI handles forms, spreadsheets, standardized email formats, and consistent document layouts reliably. One-off or unstructured input makes consistent output nearly impossible.

Verifiable outputs. You need a way to check whether the result is correct without extensive manual review. Without that, you cannot run a supervised trial or catch degradation early.

When scoring candidates, weight three things: how much weekly time the task consumes, how much pain and error the manual version generates, and how self-contained the workflow is—clean inputs, clear outputs, minimal exceptions. Strong scores on all three is where to start.

Where to Look, Organized by Function

Across five common SMB functions, the most tractable targets share a pattern: AI handles extraction, drafting, and routing; a human approves, sends, and makes the final call.

Sales and marketing tend to surface the most immediate wins. Getting inbound inquiries to the right person without manual triage, eliminating the time reps spend on post-call data entry, and turning call recordings into structured notes are all well-understood problems. Content repurposing—converting a webinar or long-form guide into shorter formats—works well because a human reviews the output before anything goes public. Lead scoring and deduplication round out a typical first roadmap for this function.

Customer support is high-volume and repetitive by design, which makes it a natural fit. Ticket tagging and routing, reply suggestions drawn from similar past resolutions, and generating help-center articles from resolved threads are low-risk entry points. Email thread summarization lets agents come up to speed on multi-touch conversations without reading every message. The consistent pattern: AI reduces handling time; a human owns the customer relationship.

Operations and admin work is often underestimated as an automation target. Pulling structured data from vendor documents, PDFs, or intake forms is well within current capability. Shared inbox triage—flagging urgency, surfacing duplicates, suggesting routing—reduces cognitive load without removing human oversight. Meeting documentation and status update generation are also solid targets, especially for teams running lean.

Finance and back-office workflows are usually rule-heavy and data-dense, which plays to AI's strengths. Extracting line items from invoices and receipts, matching purchase orders to payments, and categorizing expenses are common early deployments. Drafting collections follow-up emails and producing plain-language summaries of financial reports for non-finance stakeholders are lower-risk wins. Anomaly flagging—surfacing transactions outside expected ranges—becomes worth exploring once the simpler extraction flows are running reliably.

Internal knowledge processes are easy to overlook but often show fast, visible results. Building a searchable Q&A layer over existing policy documents lets staff get answers without routing every question to HR or legal. Generating onboarding materials from SOPs and internal wikis reduces the load on senior employees. Surfacing relevant internal resources in response to queries—rather than expecting people to know where to look—is particularly useful as headcount grows.

Where This Approach Tends to Break Down

Two failure modes appear across every function.

The first is automating a flawed process. If the upstream data is inconsistent or the workflow carries unresolved exceptions, automation does not fix that—it runs the same problems faster and at higher volume.

The second is removing human judgment from decisions that carry real accountability. Drafting, sorting, and extracting are fair targets. Approving, sending, and deciding are generally not—at least not before a period of supervised operation that builds team confidence in the output quality.

The sequence that works: start with what is frequent, well-defined, and genuinely annoying. Build confidence through measurable results before expanding scope. That sequencing matters more than which platform you choose.

The A-share quant tool that refuses to pick stocks

Reno Lu — Fri, 10 Jul 2026 15:26:30 +0000

The most telling line in tickflow-stock-panel's README is not a feature. It is a refusal. The project states plainly what it will not do: no "AI stock picking," no "limit-up prediction." For a self-hosted quant workbench that leans on large language models throughout, drawing that boundary up front is a deliberate design choice, and it shapes how the rest of the tool fits together.

A quant workstation that keeps the human in the loop

tickflow-stock-panel is a self-hosted, zero-ops workbench for China's A-share market, built around screening, monitoring, and backtesting. It runs from a single Docker container or a dev script that starts the FastAPI backend on port 3018 and a React frontend on 3011. The data comes from the TickFlow source, and the author is explicit that this is a personal open-source project with no official affiliation.

The LLM shows up in specific, bounded places rather than as an oracle. It generates screening strategies from a prompt and can migrate hand-written code into the strategy format. It produces a four-dimension read on a single stock covering technicals, fundamentals, financials, and news. It writes an after-hours market review that you can schedule, push to Feishu, or download as Markdown. In every case the AI describes or drafts; it does not tell you what to buy. The README reinforces this with a disclaimer that the tool is for learning and research only and offers no investment advice.

That framing matters because the AI is optional at all. Leave AI_API_KEY blank and the AI features simply switch off. When enabled, it talks to any OpenAI-compatible endpoint, with DeepSeek, Qwen, and Ollama named as examples, so a user can run the whole analysis loop against a local model if they want to.

The architecture bets on Polars, not pandas

The stack choices read like someone who has felt pandas get slow on wide tables. Screening runs on Polars and claims millisecond scans across the full A-share universe against 18 built-in strategies plus custom conditions. Indicators like MA, EMA, MACD, RSI, KDJ, and Bollinger bands are computed in one pass and written to enriched Parquet files. Queries go through DuckDB. Storage is Parquet on disk.

The interesting detail is how the project fences off pandas. The README calls vectorbt "the entire project's only pandas boundary." Backtesting needs vectorbt, vectorbt needs pandas, so pandas lives there and nowhere else. That is a clean way to contain a heavy dependency instead of letting it spread through the codebase.

Backtesting itself covers three modes and models the frictions that make A-share results realistic: T+1 settlement, commissions, slippage, and stop-loss. Progress streams to the UI over server-sent events, handled by sse-starlette on the backend and APScheduler for the scheduled jobs. The monitor center runs four rule types across strategies, per-stock signals, price, and unusual activity, with AND/OR conditions and Feishu push notifications.

What the README does and does not promise

The README is generous with structure and honest about status. A roadmap marks phases 0 through 6 as done and a v2 phase, including webhook order pushing and morning and evening reports, as in progress. Several pages, including stock analysis and the review module, are labeled Beta. There are no benchmark numbers behind the "millisecond" claim and no adoption figures beyond the star count, so those stay as the author's assertions rather than measured results.

For someone building their own A-share tooling, the value here is less any single feature and more the shape of the decisions: a single-container deploy, a Polars-first data path with pandas quarantined to one module, and an LLM used as an assistant that never crosses into giving recommendations.

GitHub: https://github.com/shy3130/tickflow-stock-panel

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Dao Code turns DeepSeek's cache pricing into an agent architecture

Reno Lu — Thu, 09 Jul 2026 15:52:58 +0000

Dao Code makes a bet that most coding agents avoid: instead of paying for quality with an expensive frontier model, it wrings quality out of a cheap one by treating the prefix cache as a first-class engineering surface. The whole project is organized around the fact that DeepSeek's prefix-cache hit price is roughly 1/120 of a miss, and that ratio changes what you can afford to do.

The cache is the architecture

Most agents bolt memory and self-review on top of the model and eat the token cost. Dao Code inverts that. It keeps the system prefix, tool table, and memory byte-stable so DeepSeek's cache keeps hitting, then runs its heavier machinery on forks that reuse that same main prefix cache. Reflection, cross-session memory, and refocusing all ride the cache instead of paying full freight. The README frames the design goal plainly: cross-session memory and a continuous self-correction layer that add almost no token cost.

That claim comes with receipts. The team ran seven SWE-bench-style tasks on real open-source repos (valibot, date-fns, es-toolkit, sqlglot, hono), pushed 3.89M input tokens, and logged a 95.8% aggregate cache hit rate, ranging from 85.4% to 97.7% per task. A full feature cycle of read, edit, test, and self-review reportedly runs ¥0.07 to ¥0.21, averaging ¥0.15; all seven tasks together came to ¥1.07. Every figure traces back to a per-run agent.log, and you can replay the accounting with /cost. Pricing the same token traces under each vendor's official rates, the README puts the total at roughly 30x cheaper than Claude Opus 4.8 and 18x cheaper than Sonnet 4.6, and it credits the high hit rate to Claude too, in Claude's favor.

Whether those multiples hold on your workload is a separate question, but the honesty of the setup is notable. The tasks are real bug fixes, the test files are hidden from the agent to block reward-hacking, and there's a npm run accept:cache command that runs a live multi-turn conversation so you can watch the hit rate climb from cold start to steady state yourself.

Availability as a design constraint

The second thing Dao Code optimizes for is being able to run at all. The README is direct about its context: it is Chinese-first and targets users in mainland China, where Claude Code needs an Anthropic account and network access, and GLM's coding quota is hard to grab. DeepSeek, by contrast, is register-and-go and directly reachable there. That framing explains a lot of the project's priorities that would otherwise read as odd for a Claude Code clone.

And it is fairly openly a Claude Code clone in its surface area. Dao Code mirrors the familiar kit: 24 tools, layered allow/ask/deny permissions plus a smart auto approval mode, Skills, MCP over stdio and HTTP/SSE, Hooks on five lifecycle events, custom subagents, slash commands, and plugins. It reads Claude Code config, so existing setups carry over. The differentiators sit underneath: shadow-git checkpoints that snapshot via /restore and /rewind without touching your real .git, auto-compaction to carry long tasks past the context limit, and a /audit cache command that fingerprints exactly what broke the cache across four dimensions.

The reflection layer

The self-correction machinery is worth calling out because it is where the cache economics pay off. Three forks handle it: a Challenger that questions the premise on a failure streak, a Refocuser that restates the original goal every N turns to fight scope creep, and a Reply-challenger that fires when you re-raise the same problem. There's also a constitution-style priority order where safety and truth outrank your current instruction, which outranks Dao Code's own cache discipline, which outranks skills and memory. A third-party skill can change how work gets done but never the safety or cache floor.

Dao Code is TypeScript, MIT-licensed, and installs via a one-line script, npx dao-code, or from source. It's early (created June 2026, a small contributor base), and the benchmark set is seven to fourteen tasks, not hundreds. But the core idea is specific and testable: build the agent so its expensive habits live in the cheap part of the bill.

GitHub: https://github.com/tigicion/dao-code

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

n8n's real bet: closing the prototype-to-production gap for AI agents

Reno Lu — Wed, 08 Jul 2026 21:03:28 +0000

The thing worth noticing about n8n is not the visual canvas or the 1500+ integrations everyone screenshots. It is that the project treats "prototype to production" as the actual problem for AI agents, and spends its design budget on the parts that decide whether an agent survives contact with real work.

Most agent demos stop at the point where the model returns something plausible. n8n starts there and keeps going.

Model flexibility as an architecture choice

n8n's README makes one promise that matters more than it sounds: connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture. In practice that is the difference between an agent you can maintain and one you rewrite every time a vendor changes pricing or a better model ships.

If you have built anything real on a single model API, you know the coupling that creeps in. Prompt formats, tool-call schemas, token limits, and quirks leak into your code until the provider is load-bearing. Treating the model as a swappable node instead of a hard dependency is an architecture decision, and n8n makes it the default rather than an afterthought.

The parts nobody demos

The capability list is honest about where the work actually is. n8n calls out logic, tool use, human approvals, and full observability as first-class pieces of a multi-step workflow. Those four are what separate a notebook that worked once from a system you can put in front of a customer.

Human approvals are the tell. An agent that can pause, hand a decision to a person, and resume is admitting the thing most demos hide: you do not want a fully autonomous loop touching anything that matters until you have watched it behave. Building that pause into the workflow engine, rather than bolting it on later, is a choice you only make after running automation in production and getting burned.

The same goes for self-hosting with role-based access and audit trails. If your agent reads sensitive data, "just call the hosted API" stops being an option. n8n lets you run the whole thing on your own infrastructure, which is less exciting than a cloud demo and far more useful when compliance is in the room.

You can also drop into code when the visual layer runs out. JavaScript, Python, and npm packages are available inside a workflow, so the canvas is a starting point, not a ceiling. That matters because the last ten percent of any real integration is always the part no pre-built node covers.

Fair-code, stated plainly

n8n is not open source, and it does not pretend to be. It is fair-code under the Sustainable Use License: the source is always visible, you can self-host, and you can extend it with your own nodes, while commercial use has limits the license spells out. That is a deliberate tradeoff, and naming it plainly is more useful than the usual dance around the word "open."

For a builder the calculus is simple. You get source you can read, infrastructure you control, and a large library of existing integrations and templates to start from, in exchange for licensing terms you should read before building a business on top. Knowing that up front is worth more than a permissive badge that turns out to have fine print anyway.

Try it with one line, npx n8n, or a single Docker command, and you are looking at the editor in a minute. The interesting question is not whether the canvas is pretty. It is whether treating production concerns as the main event, instead of a follow-up, is how more agent tooling should be built. n8n is a large, well-supported argument that it is.

GitHub: https://github.com/n8n-io/n8n

OpenScience runs the whole research loop, not just the reading

Reno Lu — Wed, 08 Jul 2026 15:10:33 +0000

OpenScience hands an AI agent the whole scientific loop and lets it run: read the literature, form a hypothesis, write and run code, execute the experiment on real compute, then write up the result. It is a research workbench, not a chat window, and it treats the messy middle of science as the part worth automating.

What the loop actually covers

Most AI research tools stop at "help me understand this paper" or "draft this section." OpenScience aims wider. You give it a goal and it works through literature review, hypothesis, code, experiment, analysis, and write-up in one continuous session. The README describes a default research agent backed by biology, physics, and ml specialists, plus critique and literature-review sub-agents and a read-only plan mode for when you want to see the approach before anything runs.

The connective tissue is a set of tools the agent can call directly. It queries scientific databases as first-class tools: UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, Semantic Scholar, and around thirty more. It carries what the project counts as 290+ skills spanning model training (DeepSpeed, PEFT, TRL), evaluation, dataset work, molecular and clinical biology, cheminformatics, LaTeX and figures, and cloud compute through providers like Modal and Tinker. That inventory is the difference between an agent that talks about an experiment and one that can actually run it.

A local server pretending to be a lab bench

OpenScience runs as a local server that hosts the workspace UI, the agent runtime, and the tool layer. The interface is a browser workspace with a file tree, editor, terminal, and session history, plus inline rendering for molecules, structures, genomes, and plots. So when the agent generates a protein structure or a plot, you see it in place rather than as a file path you have to go open. Sessions, artifacts, and provenance land on disk and can be shared as links.

The model story is deliberately open. It works with any frontier or open-weight model from Anthropic, OpenAI, Google, and dozens of other providers, using your own API keys, and no account is required. Models are routed per request, so switching providers or dropping in a local model does not change anything else in the setup. The README is explicit that bring-your-own-key usage is always free and never gated. There is a managed platform called Atlas that offers curated models billed from a prepaid wallet, cloud compute, and a persistent research graph, but the docs repeat that OpenScience works with Atlas and never requires it.

Getting started is a two-line affair: npm install -g @synsci/openscience then openscience, or npx synsci if you would rather not install globally. Set a provider key like ANTHROPIC_API_KEY, and the workspace opens in your browser. It is built on Bun and TypeScript, with a documented layout separating the CLI backend, the workspace frontend, the docs site, a TypeScript SDK, and a plugin runtime.

The honest part: no sandbox

The security section is worth reading before you point this at anything sensitive. The agent is not sandboxed. The README states plainly that the permission system keeps you aware of what the agent is doing but is not an isolation boundary, and it tells you to run inside a container or VM if you need isolation. It does filter provider and synced credentials out of subprocess environments and redacts them from output, so keys are handled with some care. Still, an agent that writes and runs code, opens a terminal, and executes experiments is an agent with real reach on your machine.

That candor fits the shape of the project. OpenScience is trying to automate the parts of research that involve running things, not just reading them, and running things carries risk the tool does not hide. Whether the specialist agents and 290+ skills hold up on genuinely hard problems is something the README cannot tell you. What it does establish is the ambition: a model-agnostic, Apache-2.0 workbench that takes a goal and tries to close the entire loop from question to write-up.

GitHub: https://github.com/synthetic-sciences/openscience

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

MiMoCode's bet is memory, not the model

Reno Lu — Fri, 03 Jul 2026 15:02:00 +0000

MiMoCode's bet is memory, not the model

Most terminal coding assistants forget everything when the session ends. MiMoCode, Xiaomi's terminal-native coding agent, is built around the opposite assumption: that the useful part is what the agent remembers between sessions. It is a fork of OpenCode that keeps the familiar TUI, multi-provider support, LSP, and MCP, then layers on a persistent memory system meant to hold a deep understanding of your project across runs.

You can start it with zero configuration through a free-for-now "MiMo Auto" channel, point it at any mainstream LLM provider, or import your existing Claude Code authentication in one step. Install is a one-line script or npm install -g @mimo-ai/cli, then mimo; the source lives in the XiaomiMiMo/MiMo-Code repository.

The memory and context machinery

The memory system is concrete, not a slogan. Project knowledge lives in a MEMORY.md, structured session state in a checkpoint.md maintained automatically by a checkpoint-writer subagent, scratch notes in notes.md, and per-task logs under tasks/<id>/progress.md. All of it is searchable through SQLite FTS5 full-text search and injected automatically when a session resumes, so the agent does not relearn your project every time.

The context management is the part worth borrowing ideas from. MiMoCode decides when to checkpoint based on the model's context window, and when context nears the limit it rebuilds from the latest checkpoint, project memory, task progress, and recent messages rather than just truncating. A token budget with importance ranking controls how much of that re-enters context. For anyone who has watched a long agent session degrade as it fills its window, this is the right problem to attack.

Two more features stand out. A /goal command sets a stop condition, and when the agent tries to stop, an independent judge model checks whether the condition is actually met, aimed squarely at the "optimistic stop" failure where autonomous agents quit too early. And /dream and /distill mine recent session traces to extract durable knowledge into memory and package repeated manual workflows into reusable skills.

Where it fits, and the caveats

The source is MIT, but use is also subject to a separate use-restrictions file and, for the hosted MiMo services, Xiaomi's terms, so read both before building on it commercially. As a fork tracking OpenCode, MiMoCode inherits that project's strengths and its churn, and the free MiMo Auto channel is explicitly time-limited, so price in a real provider for ongoing use.

If you already live in a terminal coding agent and your frustration is that it forgets, MiMoCode is worth a session or two specifically to see whether the memory and context-reconstruction design holds up on a real project. The model matters less here than the scaffolding around it, which is an unusual and welcome thing to be able to say about a coding assistant.

GitHub: https://github.com/XiaomiMiMo/MiMo-Code

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

With Vercel's eve, your AI agent is a directory

Reno Lu — Thu, 02 Jul 2026 15:06:28 +0000

With eve, your agent is a directory

Vercel's eve makes a bet that sounds almost too simple: an AI agent should be a folder. Instead of wiring an agent together in code, eve puts its core capabilities in conventional files and directories, so an agent is something you can inspect, diff, and operate the way you already handle the rest of a project. It is a filesystem-first framework for durable agents, currently in beta.

The structure is the whole idea. An eve agent lives under an agent/ directory: instructions.md holds the always-on system prompt, tools/ holds typed functions the model can call, skills/ holds procedures loaded on demand, channels/ connects message surfaces like HTTP, Slack, or Discord, and schedules/ holds recurring cron jobs. Each capability has an obvious home, which means a new engineer can read an agent's behavior by reading its folder rather than tracing it through a framework.

A working agent in a few files

Getting started is one command: npx eve@latest init my-agent scaffolds the directory, installs dependencies, initializes Git, and starts an interactive terminal UI. A minimal agent is genuinely minimal. You write an instructions.md, drop a typed tool in tools/ defined with defineTool and a Zod input schema, and pick a model in agent.ts with defineAgent. That is a working agent, and you extend it with human-in-the-loop prompts, subagents, and schedules from there.

One detail signals who this is for. The eve npm package ships its full documentation inside node_modules/eve/docs, so a coding agent working in your repo can read eve's own docs locally. A framework that assumes another AI agent will be reading and editing its projects is designing for how this work increasingly gets done.

Where it fits, and the caveats

The caveats are the ones any beta carries, and eve names them. It is under the Vercel public beta terms, and the framework, APIs, documentation, and behavior may change before general availability, so it is a place to prototype and learn rather than to anchor a production system today. The typed-tool, Zod-schema approach will feel natural to a TypeScript team and foreign to anyone hoping to stay in Python.

If you have built an agent the usual way and ended up with a tangle that is hard to hand off, eve's premise is worth an afternoon: scaffold one, look at how little is hidden, and decide whether "the agent is a directory" makes your next one easier to operate. The idea is small, which is the point. Most of the friction in running agents is not the model, it is everything around it, and eve is an argument that the filesystem is a better place to put that everything than a framework's internals.

GitHub: https://github.com/vercel/eve

Curated by Agent Palisade — practical AI for small and mid-sized businesses.