Agentic Engineering & Ruflo — Presentation Q&A

Answers to the questions raised during the "Agentic Engineering: A new dawn" presentation, verified against a live Ruflo install (2026-06-08). Sources at the end.

1. Local vs. cloud orchestration — and can a normal laptop run multiple agents?

TL;DR: Run it locally. Your laptop is fine. The ceiling is API cost / rate-limits, not your hardware.

• Ruflo is local-first: the CLI, the MCP server, the router, hooks, the vector DB and the background workers all run as a lightweight Node process on your machine. The only thing that goes to the cloud is the LLM inference (the Anthropic / OpenAI / etc. API calls).
• "Agents" are mostly orchestration wrappers around remote LLM calls — they don't run models locally. So an M-series Mac with 16 GB RAM runs many concurrent agents easily. Typical footprint (RSS on an M-series Mac): the MCP server ~4 MB idle / ~30–40 MB warmed, the supervisor daemon ~70 MB (a few hundred MB once warmed), the whole idle stack ~135 MB. The real cost is the headless workers — each spawns a full claude process at ~250 MB, so a 6-worker swarm peaks around ~1.5–2 GB. The daemon won't even start a worker once free memory drops below a threshold (default 5% on macOS) — it self-throttles rather than exhausting RAM. The neural / SONA / HNSW bits are tiny WASM/Rust, sub-millisecond, CPU-only.
• The real limits when running lots of agents: token spend and provider rate limits. That's a budget problem, not a "best computer" problem. (Local hardware only matters if you opt into local models via Ollama / RuVLLM — see Q2.)

2. Model routing — only Claude (Opus/Sonnet/Haiku), or other models (and RuVLLM) too?

TL;DR: No — it is not Claude-only. Routing covers the Claude tiers (Haiku/Sonnet/Opus), other providers through OpenRouter (GPT, DeepSeek, Mixtral, …), Ollama (cloud or self-hosted), any OpenAI-compatible endpoint, and local models through RuVLLM. A learning bandit picks the Claude tier; environment variables pin the provider per call; and a built-in multi-provider router adds cost-based selection and failover. The other models you already have access to are in scope.

• Claude-tier bandit. Ruflo chooses among Haiku, Sonnet, and Opus with a cost-adjusted Thompson/Beta multi-armed bandit: hooks_model-route samples a tier, hooks_model-outcome updates the Beta(α,β) priors, and the priors persist across processes (.swarm/model-router-state.json). A $0 Agent-Booster tier (WASM, ~1 ms) handles trivial structural edits ahead of the bandit. agent_execute and the hooks use this by default.
• Cross-provider dispatch. agent_execute sends the request to OpenRouter (real HTTP to openrouter.ai), Ollama (cloud or self-hosted), or Anthropic, selected by environment variable: RUFLO_PROVIDER=openrouter|ollama, OPENROUTER_API_KEY (+ OPENROUTER_BASE_URL/_DEFAULT_MODEL), OLLAMA_API_KEY/OLLAMA_BASE_URL, ANTHROPIC_API_KEY. A missing key returns an error instead of silently falling back.
• Cost-optimizing multi-provider router. Ruflo includes a multi-provider router over five providers (Anthropic, OpenRouter, Gemini, Ollama, ONNX) with manual, rule-based, cost-optimized, and performance-optimized modes and a fallback chain that retries the next provider on error. Its cost optimizer holds a per-token price table (Haiku $0.00025/$0.00125, Sonnet $0.003/$0.015, Opus $0.015/$0.075, Gemini Flash $0.0005/$0.0015, Agent-Booster $0, per 1K), picks a model by Quality/(Cost×Latency), routes trivial tasks to the free Agent-Booster, drops to the cheapest model once the budget is exceeded, tracks spend against an Opus baseline, and emits budget alerts. It runs behind Ruflo's proxy and is exposed as MCP cost-optimizer tools. Ruflo's swarm uses the Claude-tier bandit by default; this router is opt-in.
• Local inference + self-learning (RuVLLM). RuVLLM runs small local models (GGUF, llama.cpp, ONNX, WASM) at no API cost and supplies cross-provider chat-prompt formatting and the SONA / MicroLoRA learning backend; per-call adapters update numeric state such as quality_ema with NaN-safe EWC++.

Choosing a path: the bandit picks the Claude tier for ordinary agent work; RUFLO_PROVIDER pins a call to one provider; the multi-provider router adds cost-based selection and failover; Ollama, ONNX, or RuVLLM serve local inference at no API cost.

3. What does the "24/7 harness" actually look like? (does it spend tokens?)

TL;DR: The idle daemon does NOT spend LLM tokens; the event/cron-triggered workers DO when they fire. "24/7" = a near-free supervisor plus workers that each cost tokens per run.

How it actually behaves:

• The supervisor daemon is mostly idle and ~free. Note there are actually two daemons here: Claude Code's own supervisor (~/.claude/daemon.log) and Ruflo's worker daemon (<repo>/.claude-flow/logs/daemon.log). The Claude Code supervisor log is almost entirely [supervisor] workers=0, spare-process maintenance (bg spare spawned), and auth: token still valid — those "token" lines are session/auth-credential refreshes, not LLM tokens (and they're emitted by the Claude Code binary, not Ruflo). Idle ≈ $0 — and Ruflo's own worker daemon agrees: a cron tick with nothing to do completes in 1–3 ms.
• But background workers genuinely call the model. Ruflo's worker daemon shells a headless model per fire — it runs claude --bare --print, one model tier per worker (audit→Haiku, optimize/testgaps→Sonnet, learn→Opus). The headless prompt and its completion are written under .claude-flow/logs/headless/ = real token spend. (.claude-flow/data/pending-insights.jsonl is just queued local edit events, no LLM.)
• The token-spending machinery is the worker/loop layer. ruflo-loop-workers (cache-aware /loop + CronCreate) and ruflo-autopilot (autonomous /loop completion) wrap the workers, but the scheduling + headless spawn live in the worker daemon. Each scheduled worker — testgaps, audit, optimize, map, consolidate, learn — fires a headless LLM prompt on its interval. ruflo-cost-tracker attributes per-agent/model cost from the session JSONL (real per-tier USD pricing: Haiku 0.25/1.25, Sonnet 3/15, Opus 15/75 per 1M) and raises budget alerts at 50/75/90/100%. Note on "enforce": the 100% HARD_STOP is an advisory recommendation, not an automatic cutoff — nothing currently gates dispatch on it (hard circuit-breaking is a separate, not-yet-wired budget breaker).

So: "always on" = a cheap idle supervisor + workers that do cost tokens each time they run. Bound it with ruflo-cost-tracker alerts and the worker schedules. The cadences are configurable per project in .claude/settings.json (claudeFlow.daemon.schedules); the shipped defaults are 30 min (audit) / 60 min (optimize). claudeFlow.daemon.autoStart defaults to false, so the worker daemon only runs once it's explicitly started — don't conflate that with mcp.autoStart, a separate key for the MCP server.

4. How do we share harness-learnings?

TL;DR: The memory that's actually worth sharing is ADRs + MEMORY.md — and those belong in git. The "federated / shared memory" plugins are alpha and do NOT give a live shared team brain today.

Git is the real mechanism. A large part of the durable, valuable "memory" is decision/architecture knowledge, which Ruflo already shapes into git-committable files:

• Ruflo auto-generates ADRs (MADR format) into /docs/adr (e.g. docs/adr/ADR-0001-…, ADR-0002-…). DDD artifacts go to /docs/ddd.
• Claude Code's MEMORY.md files are plain markdown.
• Commit them → everyone gets them on git pull → each engineer's Ruflo re-indexes them locally for semantic recall (ruflo-rag-memory memory-bridge). This is the working "share learnings" loop.

Investigated the federated / shared-memory plugins (honest status):

• ruflo-federation (alpha): zero-trust peer-to-peer agent/message delegation (ed25519 identity + PII gate + trust tiers + audit + per-hop budget). It defines a memory-shaped query/share envelope, but it's send-only today — there's no inbound dispatcher, so no peer actually serves the read. Not team memory yet.
• ruflo-intelligence: local-disk only — it copies learned patterns between projects on the same machine; it has no IPFS / CID path. IPFS publishing exists separately, as a community pattern marketplace (needs Pinata API keys), and shares patterns, not your knowledge base.
• ruflo-rvf: bundles a session into a portable .rvf file for single-user portability between machines/sessions. No team/git workflow.
• ruflo-rag-memory: local cross-project recall (re-index files into local AgentDB). Local only.
• ruflo-agentdb / ruflo-ruvector: storage is local SQLite / RVF. RuVector's server / cluster modes are "Coming Soon" stubs — there is no working bare HTTP store today, with or without auth. No turnkey shared / QUIC / Postgres multi-user memory store is wired up.

Verdict: there is no live shared team brain today. Use git (ADRs + MEMORY.md + docs) as the source of truth, re-index locally per engineer, and reserve IPFS-transfer for sharing learned patterns and .rvf for occasional whole-session handoff. (See Q10.)

5. Getting started — how to get the most out of Ruflo + RuVector

TL;DR: Install all the plugins and let them run in the background — they just work. Lean on the high-value skills (ADR, DDD, goals, swarm), always use a swarm, and when in doubt just ask Claude how to apply it to your task.

1. Install all the plugins. They're built to run in the background — once enabled, the hooks, daemon, routing, memory, audits, and learning all just work; you rarely invoke anything directly. The only one most teams leave off by default is security-audit (its scanning is heavy — turn it on when you want dependency/security auditing). Manage with /plugin marketplace add ruflo, then /plugin install <name>@ruflo (toggle in /plugin; run /reload-plugins if new commands don't appear).

2. It just works in the background. Hooks + daemon route tasks, learn patterns, consolidate memory, and run audits and test-gap checks automatically. RuVector is the vector engine underneath all of that — HNSW-indexed semantic memory and recall over your code, docs, and ADRs — and it runs as part of the stack with nothing to configure.

3. Always use a swarm. This is where the real multiplier is: agent teams with hierarchical-mesh coordination, working in parallel and checking each other. Don't save it for "big" tasks — reach for the swarm by default and let Ruflo coordinate. Lean on the high-value skills:

• ADR — capture every decision as a MADR record in /docs/adr (auto-generated, git-tracked). This is your durable, portable memory.
• DDD — bounded contexts, aggregates, and domain events into /docs/ddd.
• goals — long-horizon planning and deep research (GOAP) for multi-step objectives.
• swarm — coordinated multi-agent execution; your default for real work.

4. Then explore and play. Browse the plugins, skills, and commands on this site — the catalog is large; poke at whatever's relevant to your work.

5. Read the userguide. The canonical USERGUIDE.md is the deep reference for every subsystem.

6. Most of all — ask Claude. The fastest way to get the best out of Ruflo is to ask Claude (in Claude Code) how to apply it to your task — it knows the agents, skills, hooks, and tools and wires them together for you.

6. Beyond Ruflo — enterprise-grade harnesses, what's coming, and how can CyberSec keep up?

TL;DR: The way CybSec keeps up is to stop approving tools one at a time — that's the treadmill. Standardize on a single, actively-developed framework and make it the paved road. Our recommendation is Ruflo: open-source, widely used, and — uniquely among agent frameworks — it ships its own AI-defence layer, so security is built in rather than bolted on per team. One framework you can pin, audit, and gate gives CybSec far more control than a hundred skills everyone installs at will.

Why standardizing on one framework is the control

• One supply chain, not N. You version-pin, audit, and monitor a single dependency tree instead of every engineer's random skills / MCP servers. Everything else is default-deny.
• Security built into the framework — Ruflo's edge. Ruflo ships AIDefence (prompt-injection / manipulation detection + PII gating) so every agent inherits the guardrail by default. No other mainstream framework brings its own defence layer — with the rest, each team wires its own, or skips it.
• Active development = SOTA without re-approval. A fast-moving, open-source framework absorbs new models and protocols (MCP, new providers) for you. Approve it once and ride its upgrades, instead of re-evaluating a new tool every quarter. That is how CybSec keeps up — delegate frontier-tracking to one trusted framework rather than chasing it per-tool.
• A single allow-list is actually enforceable. "Only the approved framework runs" is a policy you can implement and gate. "Approve whatever anyone finds" is not — and the free-for-all is exactly the surface behind the skills-marketplace-poisoning and hook-RCE incidents below.

Govern it like any dependency — that's the whole bar

You don't need to distrust Ruflo to govern it well; standardizing is the control. Give it the same basic hygiene every third-party dependency gets — pin versions, scope its credentials and MCP access, run it under your normal permission/sandbox modes — and the enterprise wrappers you already own (IdP/SSO, audit, egress proxy) sit around it exactly as they would any tool. Do that once, for the one framework, and low-risk use flows.

The paved road, concretely

Build it once, then let low-risk use flow:

1. Approved-framework + MCP allow-listing (default-deny; teams pull from one vetted registry). Copilot, Claude Code, and GitHub Enterprise all support MCP allow-lists natively now.
2. Risk-tiering: Green (summarize / translate → light oversight) / Yellow (draft code + PRs → automated checks + human review) / Red (prod, secrets, deletes → mandatory human-in-the-loop + full audit).
3. Sandbox + permission modes by default — scoped FS / network, dry-run before write / exec.
4. One LLM gateway / proxy as the egress choke point for allow-listing, DLP, and centralized logging — but treat the gateway itself as critical supply chain (the March 2026 LiteLLM PyPI compromise was the gateway).
5. Policy-as-code + staged rollout (Microsoft open-sourced an Agent Governance Toolkit mapping to OWASP's agentic risks, Apr 2026).
6. Agent identity + least privilege — scoped, short-lived creds; no shared prod keys.
7. Observability or it didn't happen — centralized agentic audit logs.

Anchor it to standards so approvals are repeatable: NIST AI RMF + GenAI Profile, OWASP Top 10 for Agentic Apps (ASI01–ASI10, Dec 2025), ISO/IEC 42001, MITRE ATLAS. The 2026 incident record is the case for a single defended framework over a free-for-all: the Claude Code hook RCE (malicious .claude/settings.json), the LiteLLM supply-chain compromise, exposed / unauthenticated MCP servers, and a skills-marketplace poisoning wave — each an agent-tooling attack, exactly the surface that standardizing on one defence-equipped framework shrinks.

7. Can this be Microsoft-agnostic / work with Copilot, and scale to new + existing programmers?

TL;DR: Two layers, two answers. The model is flexible — run the Copilot proxy and you can route to any model, so you are not tied to an Anthropic contract for inference. The harness, though, is Claude Code: that's where Ruflo's lifecycle hooks and deepest integration live, so to get everything out of Ruflo you run it in Claude Code. (Codex is supported, but with less integration and fewer lifecycle hooks — Claude Code is the way to go.) Either way there's no real lock-in: your decisions live as ADRs and the code is generated from them, so any framework can pick up from there.

The reframe that kills the lock-in worry. You are not betting your project on Ruflo. The durable asset is the ADRs and specs, committed to git; everything else is generated from them. Ruflo is the environment you author in, like an IDE — swap it and your ADRs and code come with you. The only thing that would not port is bespoke code that calls Ruflo's own runtime APIs — and most teams never write that.

Adoption is light — it is habits, not a tool to learn:

• Models are flexible: run the Copilot proxy (or OpenRouter / BYOK) to route any model — a Microsoft / Copilot shop is not tied to an Anthropic contract, and Azure AI Foundry even hosts Claude.
• The harness is Claude Code: run Ruflo inside Claude Code to get the full lifecycle hooks and integration — that's how you get everything out of it. Codex is supported, but second-class (less integration, fewer hooks).
• Let it run in the background — once it's in Claude Code, the hooks + daemon do their thing; nobody has to learn an orchestration system to benefit.
• Teach a handful of habits: use a few skills — /adr, /ddd, /goals, /swarm — and shift to spending ~80% of the time writing specs as ADRs. That is the whole behaviour change, and the ADRs are what make the work portable and the agents good.

Supporting facts (2026):

• Multi-model is solved on Copilot: native picker for Claude Sonnet 4.x / Opus 4.x (incl. Opus 4.8), GPT-5.x, Gemini; BYOK GA Apr 2026; Azure AI Foundry hosts Claude — Microsoft shops can run Claude with no Anthropic contract.
• Portability rides open standards you already use: MCP (tools) + AGENTS.md (context). This repo carries both CLAUDE.md and AGENTS.md — the right hedge. Push reusable logic into MCP servers + AGENTS.md and a move to Copilot is a config change, not a rewrite.
• Scaling to a mixed team: Copilot's strongest area — seat management, IdP/HRIS provisioning, org policies, usage dashboards, SIEM audit. New programmers get guardrails via AGENTS.md + review-on-PR + the four skills; experienced ones get BYOK + custom agents.

Copilot proxy setup: see the Copilot guide on the Ruflo docs site.

8. Do I need a Ruflo instance per repository? Per engineer?

TL;DR: One install per machine/user (serves all repos). Memory is per repo — but the part worth sharing is just files in git (ADRs, MEMORY.md), so a team shares memory by sharing the repo.

• Binary + MCP server + daemon = per-user / global, shared across all repos. One daemon, many repos (it lives in ~/.claude/daemon/, and plugins are enabled globally in ~/.claude/settings.json).
• Config + memory / learning = per-repo (project-local). Each repo gets its own .claude-flow/, .swarm/state.json, and optional .rvf — effectively a separate "brain" per project.
• Per engineer: by default each engineer runs their own local instance with their own local memory. But the memory that actually matters for a team is the files in git — your ADRs and MEMORY.md — so committing them (see Q4/Q10) is how everyone shares one brain. There's no built-in always-on multi-user server everyone connects to.

9. New computer — how do the learnings transfer?

TL;DR: Copy the data dirs (or export/import). Best practice: keep durable knowledge in git so a clone restores most of it automatically.

• Manual: copy the repo's .claude-flow/ + .swarm/ (+ any .rvf) and relevant ~/.claude/ bits to the new machine. The .rvf "single-file brain" design makes this clean (ruflo-rvf).
• Tooling: ruflo memory export → import, ruflo session export → import, ruflo ruvector backup create → restore.
• Recommended: commit the shareable knowledge (CLAUDE.md / AGENTS.md, ADRs / docs, exported memory you want versioned) to the repo. Then "new computer" = git clone and you're 90% there. The only machine-specific residue is locally-learned routing weights / the vector store, which you move by file copy or export/import. Don't rely on any auto-sync — there isn't one.

10. How does Ruflo actually solve "team memory"?

TL;DR: Honestly — it mostly doesn't, automatically. There's no shipped real-time shared brain. "Team memory" today = git (ADRs + MEMORY.md) re-indexed locally per engineer.

• Ruflo memory is local-first, per-machine, per-repo. The real-time multi-writer sync that "team memory" implies (QUIC transport, CRDT conflict resolution) is planned / not shipped. Be skeptical of any "shared collective intelligence" framing.
• What actually gives you team memory, ranked:
  1. Git as the memory bus (recommended). Commit CLAUDE.md / AGENTS.md, ADRs / docs, and the exported memory you want shared. Reviewable, auditable, conflict-handled by the tool your team already trusts. Each engineer re-indexes locally via ruflo-rag-memory.
  2. Export/import bundles. ruflo-intelligence (IPFS, shares learned patterns by CID) and ruflo-rvf (whole-session .rvf handoff) — single-user-portability ergonomics, DIY for teams.
  3. ruflo-federation / ruvector server mode. Alpha: federation does P2P agent delegation (not a shared store), and the ruvector server is a single bare DB with no multi-tenant/auth. Not a turnkey shared brain.

---

Verification & sources

Ruflo-internal claims were verified against a live Ruflo install — the running MCP server and worker daemon, the configured plugins, and the project's runtime directories; external/landscape claims against primary web sources (June 2026).

Key sources

• Ruflo / claude-flow: github.com/ruvnet/ruflo + USERGUIDE + .claude-plugin/marketplace.json; npm ruflo, @claude-flow/cli, @claude-flow/plugins, @claude-flow/plugin-agent-federation, agentdb, ruvector, @ruvector/ruvllm
• GitHub Copilot: supported models docs, BYOK (Apr 2026) changelog, Agent HQ announcement
• Microsoft: Agent Framework overview, Foundry Agent Service docs
• Anthropic: Claude Code on Team & Enterprise
• Security / governance: OWASP Top 10 for Agentic Apps, NIST AI RMF + GenAI Profile, ISO/IEC 42001, MITRE ATLAS; LiteLLM compromise (Datadog Security Labs)