steveandClaude Opus 4.8
13be3022fd
Two gaps surfaced by a live fan-out smoke in a downstream host (mort): 1) A single-loop run that exhausts its step budget (ErrMaxSteps / ErrToolLoop) returned empty Output + a hard error, discarding all the reasoning it had produced — unlike the phased path, which already salvages a partial transcript and continues. Add opt-in single-loop salvage (Defaults.SalvageSingleLoopMaxSteps, default off): on budget exhaustion with empty Output, reconstruct a best-effort answer from the step narration (reusing salvagePhaseTranscript) and downgrade the run to a successful partial result. Off by default so a structured-output host keeps its clean hard error; an interactive host opts in. 2) RunnableAgent carried no tool-call ceiling — MaxIterations bounds STEPS, but one step can dispatch several tool calls, so a host's "max tool calls" cap had nowhere to land. Add RunnableAgent.MaxToolCalls (<=0 = unlimited, backward-compatible): the step observer counts executed calls and, once the cap is reached, stepCeilingOption forces the loop to exit; the resulting ErrMaxSteps is relabeled to the new ErrMaxToolCalls sentinel. Enforced single-loop only for now (phased is a follow-up). A cap hit is budget exhaustion, so salvage recovers its partial reasoning too. isPhaseBudgetExhaustion becomes the shared isBudgetExhaustion (now also matching ErrMaxToolCalls) so the phased and single-loop paths never drift, and the RunStateAccessor now reports the real tool-call cap (was hardcoded 0). Additive + backward-compatible: new optional DTO field, new opt-in Defaults flag, new exported sentinel; unlimited/off reproduce prior behavior exactly. No new dependencies (go mod tidy clean). Tests cover salvage on/off/no-prose, cap enforcement + sentinel, cap+salvage, unlimited no-op, and cap-overrides-critic. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01Q1eJh5NVR11z6RzyxLANMK
executus
⚠️ This project is vibe-coded. executus is written almost entirely by an AI coding agent (Claude), with a human steering at the design and review level rather than typing the code. That's a deliberate choice, stated up front — the same way gadfly is. Read the code before you depend on it, pin a version, and file issues if something looks off. It is offered as-is.
A batteries-included base for building LLM agent harnesses in Go. Import it, do a little wiring, and you have agentic capabilities: a bounded run loop, a tool registry with a suite of common tools, context compaction, config-driven model tiering and failover, structured output, and parallel fan-out — with sensible defaults so a brand-new project is agentic with almost no setup, and pluggable seams so a serious host can swap in its own storage, config, delivery, and tools.
executus sits strictly above majordomo — the lean LLM substrate (agent
loop, canonical llm types, providers, media normalization, model parsing /
failover / tiering). majordomo stays the substrate; executus is the opinionated,
batteries-included layer on top. executus requires no changes to majordomo.
Status
Early. Being extracted, phase by phase, from the agent layer of mort (a Discord
bot) — mort and gadfly are the first two consumers (heavy and light). See
CLAUDE.md for the architecture and the extraction roadmap (P0–P6).
Available today:
run/— executus is runnable.run.Executorties model resolution, the tool registry, majordomo's agent loop, context compaction, run-bounding, and step/audit instrumentation into oneRun(ctx, RunnableAgent, inv) Result, with every host concern behind a nil-saferun.Ports(Audit/Budget/Critic/ Checkpointer/PaletteSource/Delivery/InputFiles). Seeexamples/minimal.model/— config-driven tier resolution + failover over majordomo, with pluggableUsageSink/TraceSinkandGenerateWith[T]structured output.tool/— the tool registry + 3-stage permission model + SSRF guard.compact/— the per-run context compactor.lane/— bounded worker pool with fair-share queueing (run- and provider-concurrency).fanout/— programmatic N×M swarm with bounded global + per-key concurrency.config/,deliver/,identity/— host seams (config / output / identity), each with a shipped default.dispatchguard/,pendingattach/— run-safety primitives.examples/reviewer— a gadfly-shaped PR reviewer on the core only (env-config model fleet →fanoutN×M swarm →model.GenerateWith[T]structured findings → consolidation), the light-tier canary; CI asserts it pulls in no battery.
Design
Two tiers in one module (go.mod = majordomo + stdlib only):
- Core — everything a light host needs to be agentic: run loop, tool registry + common tools, model resolution, compaction, lanes, fan-out, structured output. No persistence, no scheduling.
- Batteries (opt-in sibling packages) — persona/agent nouns, saved skills, audit, run-critic, scheduling, budgets, checkpointing. Each is nil-safe and ships a default, so you add only what you use.
Persistence that needs a real database lives in a separate nested module
(contrib/store, pure-Go SQLite) so the core never drags in a DB driver — a
static-binary host (gadfly) stays static.
License
TBD.