Skip to content

[Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model (Python) #8556

Description

Description

Summary

Request first-class integration of TypeSafe AI's Jev model into the Microsoft Agent Framework Python SDK, similar to what LangChain (langchain-typesafe) and Pydantic AI (pydantic-ai-slim[typesafe], TypeSafeModel) already ship.

What is Jev?

Jev is a "System One" model released by TypeSafe AI on 2026-09-15. It does not generate text. You send it a piece of state (text or JSON) plus a set of typed questions, and it returns structured decisions with probabilities in a single parallel pass:

  • Noul: yes/no probability in [0, 1]
  • Choice: pick one option from a list you define, with probabilities
  • Score: rate against an ordered scale you define

It is fast and cheap relative to frontier LLMs (vendor cites 40x–200x lower latency, $0.042 per million input tokens, output free), which makes it a good fit for the high-frequency control-plane decisions inside agent loops: routing, tool-call risk gating, scoring, escalation, model selection.

Docs: https://docs.typesafe.ai/concepts/system-one
Announcement: https://typesafe.ai/blog/introducing-system-one-models-and-jev

What problem does it solve?

Today, decisions like "is this tool call safe?", "which sub-agent should handle this?" or "is this task simple enough for a small model?" are made either by hard-coded rules or by asking the generative LLM and parsing free-form output. Jev gives typed, calibrated answers directly, with no parsing, at a fraction of the latency and cost.

Why it fits MAF

  • Maps naturally onto the Python SDK's existing extension points: FunctionMiddleware (gate tool calls before execution, alongside ToolApprovalMiddleware), AgentMiddleware/ChatMiddleware (routing, model selection), AIFunction tools, and workflow executors/routers.
  • Complements generative providers rather than competing with them: the LLM plans and generates, Jev decides.
  • Keeps parity with other major Python agent frameworks that already have official packages.

Design note: Jev is not a chat model

Every existing provider package under python/packages/ is a chat client implementing SupportsChatGetResponse. Jev cannot be exposed that way. The proposal is a separate decision-client abstraction with adapters for middleware, tools and workflows, rather than a new chat provider.

Suggested integration surface

  • New package following the existing naming convention: agent-framework-typesafe under python/packages/typesafe.
  • A JevClient exposing an evaluate call that accepts state + questions and returns typed answers with probabilities.
  • Adapters:
    • FunctionMiddleware factory for scoring/gating tool calls with a configurable threshold.
    • AgentMiddleware/ChatMiddleware factory for routing and model selection.
    • Helper to wrap a set of questions as an AIFunction tool.
    • Workflow executor/router for conditional edges.
  • Ability to pass MAF session or workflow state as the Jev state.
  • Optional confidence threshold with fallback to a generative model.

Alternatives considered

  • Calling the raw TypeSafe HTTP API (POST /v1/systemone) from custom middleware or tools. Works today, but every team rebuilds the same boilerplate and type mapping.
  • Community MCP servers for Jev. Usable through the hosting-mcp / MCP tool support, but adds a hop and loses the typed result surface.

Code Sample

# Desired Python experience: new package `agent-framework-typesafe`
from agent_framework import Agent
from agent_framework.azure import AzureOpenAIChatClient
from agent_framework.typesafe import JevClient, Noul, Choice, Score

jev = JevClient()  # reads TYPESAFE_API_KEY

# 1) Direct decision call (usable from tools, workflow executors, routers)
result = await jev.evaluate(
    state={"ticket": ticket_text},
    questions={
        "urgent": Noul("Does this require immediate attention?"),
        "department": Choice(
            "Which team should handle this?",
            criteria={"billing": "Payment issues", "technical": "Bugs", "other": "Everything else"},
        ),
    },
)
result.answers["urgent"].probability  # float in [0, 1]
result.answers["department"].value    # "billing" | "technical" | "other"

# 2) As FunctionMiddleware: score tool calls before execution
risk_gate = jev.function_middleware(
    question=Score("How risky is this tool call?", criteria=["safe", "needs_review", "dangerous"]),
    block_at="dangerous",
)

agent = Agent(
    client=AzureOpenAIChatClient(),
    instructions="You are a support triage agent.",
    middleware=[risk_gate],
)

Language/SDK

Python

Activity

  1. added
    .NETUsage: [Issues, PRs], Target: .Net
    pythonUsage: [Issues, PRs], Target: Python
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Sep 20, 2026
  2. changed the title [-][Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model[/-] [+]Python: [Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model[/+] on Sep 20, 2026
  3. changed the title [-]Python: [Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model[/-] [+].NET: [Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model[/+] on Sep 20, 2026
  4. removed
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Sep 20, 2026
  5. changed the title [-].NET: [Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model[/-] [+][Feature]: Add first-class support for TypeSafe AI's Jev (System One) decision model (Python)[/+] on Sep 20, 2026
  6. grafanaKibana commented on Sep 20, 2026

    @grafanaKibana

    Hope this will reach .NET as well

  7. IRONICBo commented on Sep 20, 2026

    @IRONICBo

    One implementation detail worth keeping in the abstraction: a Choice result should be a proposal, not authorization.

    In a browser loop we rebuild the candidate set from currently observed targets on every step, then validate the chosen domain, target type, and installed capability again in code before execution. Low confidence and stale or invented IDs fail closed. That suggests DecisionResponse should preserve stable candidate IDs and the distribution, while execution policy remains caller-owned rather than living in the provider adapter.

    It also helps to record decision latency separately from downstream tool latency; otherwise a fast decision-model result gets conflated with end-to-end workflow time.

    Concrete JS implementation: candidate construction and validation and the per-step loop. Disclosure: I maintain Jev Social.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

.NETUsage: [Issues, PRs], Target: .NetagentsUsage: [Issues, PRs], Target: Single agentpythonUsage: [Issues, PRs], Target: Python

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions