steve
aab950f1c3
Stand up the executus/run kernel foundation, decoupled from mort: - runengine.go: the shared run-loop scaffolding (MergeCancellation, CleanupContextTimeout, RunFinalizer/FireFinalizers, RunStateAccessor) moved from mort. The accessor's *skillaudit.Writer dependency is inverted to a narrow run.RunTally interface (TokenStats + ToolCallsCount) — the kernel reads live tallies without importing the audit battery. - submit.go: the legacy submit-capture compat tool (stdlib + majordomo/llm). - agent.go: RunnableAgent DTO — the kernel's view of "a thing to run" (tier, prompt, caps, palette, phases, critic config). The persona Agent and saved Skill will LOWER into this DTO so the kernel never imports a noun battery. This is the spine of the agentexec.Run(*agents.Agent) inversion. run/ builds with only majordomo + executus/tool. The executor merge (agentexec+skillexec -> run.Executor) and the nil-safe run.Ports (Audit/Critic/Budget/Checkpointer/PaletteSource) are the next P2 block. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 (P0):
lane/— bounded worker pool with fair-share queueing (run- and provider-concurrency).fanout/— programmatic N×M swarm with bounded global + per-key concurrency.config/— the host config seam (Source) with an env-var default.deliver/— the output-egress seam withDiscard/Stdoutdefaults.identity/— caller-identity seams (AdminPolicy,MemberResolver).dispatchguard/,pendingattach/,run/progress.go— run-safety primitives.
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.