Skip to content

CHANGELOG.md

Latest commit

 

History

History
37 lines (29 loc) · 8.67 KB

CHANGELOG.md

File metadata and controls

37 lines (29 loc) · 8.67 KB
Raw

Changelog

1.3.17

  • Frames: a catalogue generated from agentspecs/frames (agentspecs 0.0.12) — FRAME_CATALOGUE, getFrame, listFrames; get_frame, list_frames. A Frame is owned, scoped context (rules, terminology, goals, style, norms, process) with the Guards an output has to pass; it arrives resolved, with what it inherits through extends and its lineage.
  • Cogs: a catalogue generated from agentspecs/cogs — COG_CATALOGUE, getCog, listCogs, cogsUsing; get_cog, list_cogs, cogs_using. A Cog extends an agent spec and is equipped with Frames; its spec is a complete Agentspec (the agent, the Cog's changes, the Frames' skills, tools and MCP servers, and their context on the system prompt), beside its frames, lineage and guards.
  • Ops, Guards, Gates and Tracks: four catalogues generated from agentspecs/ops, guards, gates and tracks (agentspecs 0.0.14) by generate_ops.py — OP_CATALOGUE, GUARD_CATALOGUE, GATE_CATALOGUE, TRACK_CATALOGUE, each with get… and list…. A GuardSpec extends GuardrailSpec: a Guard arrives with the policy of the guardrail it extends, and adds its category, stages, check and signals. An OpSpec arrives resolved, with its Cogs, its Guards by stage, its Gates and its Track in it.
  • Applications: a catalogue generated from agentspecs/apps (agentspecs 0.0.15) by generate_apps.py — APP_CATALOGUE, getApp, listApps; get_app, list_apps. An AppSpec is the Appspec: an agent with an interface, rules, tests, a record and a deployment — a chat, a widget, a decision or a worker — with its face (emoji) and its permissions. It arrives with its layout and with what it names that is not enabled (setup).
  • Action classes: what every tool does to the world — TOOL_ACTIONS, SERVER_ACTIONS (read, write, send, buy, delete, publish; conditions where a tool's effect depends on what it is asked). A tool nobody classed is unknown, and unknown is the most restricted.
  • Rules: what an application does when its agent calls a tool — agent_runtimes.loop.apps (behaviour_for, classes_of, tool_behaviours, tool_escalations) and, in TypeScript, behaviourFor, classesOf, toolBehaviours, toolEscalations. One of do_it, if_asked, ask_first, leave_to_me; with no rule, reading is done and anything that acts waits for a person. APP_BEHAVIOURS and APP_ESCALATIONS, generated from agentspecs, are what both have to reproduce. Nothing calls them yet: this is the decision, not its enforcement.
  • The Appspec as a file: parseAppspec reads a YAML or JSON document in the spec's own words into an AppSpec, tolerantly — a draft opens whole, with what is wrong said beside it — and dumpAppspec writes it back, keys in one fixed order and nothing at its default, so that the same application always writes the same document. APP_SOURCES, generated from agentspecs, is what both have to give back.
  • The Appspec as a YAML file a person also edits: readAppspecYaml reports what YAML itself refuses with its line, and writeAppspecYaml(app, previous) writes an application into the file that is there — what did not change keeps its comments, its order and its quoting, an item of a list is followed by what identifies it, and a key that is new goes where the spec puts it. With no file to write into, the canonical document. Adds the yaml dependency.
  • decision_for says why a tool call was decided as it was — the rule in its author's words, or the step that decided (not connected, left out by the connection, a read-only connection, an unclassed tool, the default) — with a sentence a person reads. behaviour_for is its behaviour.
  • AppRulesCapability: an application's rules, enforced before every tool call — a pydantic-ai capability that does the reading, asks the person before what the rules say to ask about (through the tool-approval path), and refuses what is left to them, with the rule's own words. It decides a tool by its runtime name, call_tool on the tool it calls and its arguments, a catalogue tool by its id or method, and code (execute_code, run_skill_script) only when the application's shell is on, then on every tool the code names, for the worst each can do. Not attached to any agent yet.
  • loop apps validate PATH…: the instant checks of an Appspec, in a terminal and in CI — what the spec refuses and every reference that does not resolve (Not ready, exit 1), what the application can do with no rule of its own and what it reaches with its builder's account (Needs attention, exit 2 with --strict), and what it names that is not enabled. --json for CI. Depends on agentspecs >= 0.0.16, whose checks it runs.
  • Applications on a runtime: POST /api/v1/apps/configure makes the runtime's agent the one an application runs — its agent or Cog, its model and instructions, only the MCP servers it connects to, and its rules enforced before every tool call in place of the default approvals; an application its builder's checks refuse is refused (422) with the same sentences. GET /api/v1/apps/current names it; POST /api/v1/apps/decide says what it would do about a tool call without making it. CreateAgentRequest.app_spec carries the application through configure-from-spec, which no longer turns a 422 into a 500. A Cog is found where an agent of the library is looked for.
  • AppRenderer and defineAppPlugin: an application rendered in the LOOP workspace — its agent created with the application in its payload, its starters on the empty chat, the conversation alone for a chat.
  • checkApp, checkAppspec: the instant checks of an application in the page — what the spec refuses, references that do not resolve, what it can do with no rule of its own, what is not enabled — in the words loop apps validate uses, with no model call.
  • Applications are Reactor plugins on the runtime too, as they are in the page: a loop.app contribution point (agent_runtimes.loop.apps.plugins), the catalogue contributed by agent-runtimes' own plugin, an application a runtime is configured with by a plugin of its own (loop-app-<id>, its manifest carrying its name and emoji), and its rules capability an extension of its contribution that another plugin can replace. GET /api/v1/apps lists the applications a runtime knows; configure, current and decide read them from the registry. Depends on datalayer_reactor's Python contribution points.
  • AppRenderer says that an application run by a team cannot run in the page yet, instead of throwing, runs under the application's id, and keeps its plugin across renders. checkAppspec reports what the reader would otherwise replace with a default (an unknown behaviour, layout or access, a ready_at outside 0 to 1, an origin with a path…), counts a rule on a versioned tool as a rule on that tool, and says what is not enabled for every reference, as agentspecs' app_setup does.
  • make specs generates both (generate_frames.py, generate_cogs.py), resolving them with the agentspecs package of the clone it checked out, and checks out main by default.

1.3.16

  • UI plugins: what was called a UI extension. A catalogue generated from agentspecs/ui-plugins (UI_PLUGIN_CATALOGUE, getUIPlugin, listUIPlugins; get_ui_plugin, list_ui_plugins); the agent field is uiPlugin / ui_plugin, and uiExtension / ui_extension are still read by the Python model. The TypeScript Agentspec.uiExtension is renamed uiPlugin.
  • Models: Cloudflare Workers AI and AI Gateway in the catalogue and as a direct provider; route, contextWindow, zeroDataRetention, requestLogging, pricing, providerUrl, billing and aliases on a model; AI_MODEL_ALIASES, getModel, isChatModel, listChatModels (get_model, is_chat_model, list_chat_models): a chat picker leaves the typed-judgment models out.
  • Model providers: MODEL_PROVIDER_CATALOGUE, getModelProvider — who serves a model, with its terms, privacy policy and data usage.
  • Specs regenerated from agentspecs 0.0.11: four agents enabled (example-simple, worker-crawler, jupyter-notebook-compactor, example-one-trigger); of the Cloudflare models only Jev is available; the Tavily and Earthdata MCP servers enabled; events agent-output, agent-assigned and generic; the csv and json outputs and the crawl skill enabled; a memory spec says whether it is enabled (mem0 is).
  • Loop: headerContainer renders the header's controls in a host's own bar; data-loop-fullscreen-root takes that bar into full screen.

1.3.15

  • Requires code-sandboxes 1.10.0 (one subpackage per provider, no flat module paths); the identity docs import EvalSandbox from code_sandboxes.