mikehostetler

Jev as a ReqLLM model router

This Livebook installs ReqLLM directly from GitHub. It uses the model router merged in ReqLLM PR #1036 and shows a small separation of responsibilities:

1. ReqLLM normalizes the generation request.
2. An application router asks Jev for evidence.

mikehostetler

Evaluate issues with Jev and ReqLLM

Section

This notebook teaches the new ReqLLM.evaluate/4 API. It starts with one model call. It then uses a plain GenServer to manage work. It does not use Jido or a Jev.Server package.

Jev is an evaluation model. It takes one text or JSON state and a map of named questions. It returns answers, not chat text. ReqLLM sends these questions to TypeSafe and returns a normal %ReqLLM.Response{}. Our Elixir code then turns the answers into issue labels.

mikehostetler

title	Governing Risk with Agents: An Architecture Study of Jido on the BEAM
status	Working Draft
version	0.1
date	2026-07-31
author	Mike Hostetler
source_commit	17fbce2b1c53a46093be92dc59561e2a18b8f775
declared_project_version	2.3.2

mikehostetler

Lua Tool Layer for Jido/Jidoka Agents

Summary

This proposal explores a Lua-based tool layer for agents that need access to large application capability surfaces without sending every tool schema to the model on every turn.

The core idea is simple:

mikehostetler

Sparq: An App Store for Human Expertise

This is an early sketch of a big idea: what if the way experts do great work could be packaged, protected, rented, and improved over time?

Most companies have valuable expertise trapped in people's heads, private playbooks, scattered SOPs, consulting decks, Slack threads, and one-off processes. AI makes this problem more urgent. A generic AI agent can help, but it usually does not know how a great operator, manager, engineer, recruiter, salesperson, or compliance lead actually gets work done.

Sparq is an attempt to turn expert operating models into executable business capabilities.

The Core Idea

mikehostetler

Sensor Attention and Control in Jido

Status: proposal for discussion

Date: 2026-04-12

Related: agentjido/jido#253

Summary

mikehostetler

Jido.Domain

This is a concept sketch, not an implementation plan.

The core idea: Jido.Domain is the missing authoring layer above Jido.Pod.

Jido already has strong primitives:

• Jido.Agent for behavior
• Jido.Pod for durable topology

mikehostetler

Proposed RFC: Pod Runtime Lifecycle Callbacks

Status: Proposed

Author: Codex draft for discussion

Date: 2026-04-08

Summary

mikehostetler

• Prefer gh pr checkout <number> --detach for review-only work so disposable local branches do not accumulate.
• If a separate worktree is useful, give it an obviously temporary name and remove it with git worktree remove <path> when the review is done.
• After temp worktrees are removed or deleted out-of-band, run git worktree prune -v to clear stale metadata.
• Before starting substantial new work, prefer returning the root repo to a clean, current baseline with git status --short --branch, git fetch --prune origin, git checkout main, and git pull --ff-only origin main when that fits the repo workflow.
• Ask before deleting unmerged branches.
• Clean up disposable review branches like pr-<number> and *-review once they are merged or no longer needed.

mikehostetler

Jido 2.0 is here

Mike Hostetler

---

After 18 months of building, rewriting, and rethinking, Jido 2.0 has shipped. It's available on Hex now.

Jido started as a bot platform called BotHive in 2024. Then the AI wave hit and everything changed. I was already using Elixir decided to make a bet: the BEAM the best runtime for agent systems.