Jev on AWS: Building Fast AI Decision Layers with AWS
Learn how to integrate Jev with AWS to build fast, structured AI decision workflows. This article explores using Jev alongside AWS Lambda, API Gateway, Amazon Bedrock, and other AWS services for intelligent routing, tool-risk gating, and automated decision-making.
Introduction
Modern AI applications often use large language models (LLMs) for every decision. While LLMs are powerful, many application decisions do not require generating a long response.
For example:
- Should this request be routed to Agent A or Agent B?
- Is this tool call safe to execute?
- Should a customer request be escalated to a human?
- Which category does this request belong to?
- Should an automated action be allowed or blocked?
This is where Jev by TypeSafe AI can be useful.
Jev is a decision model designed to take application state and typed questions and return structured decisions such as a choice, score, or probability. Unlike a conversational LLM, it is designed to provide outputs that application code can directly use.
In this article, we will explore how Jev can work alongside AWS services to create a fast decision layer for an AI application.
What is Jev?
Jev is a System One decision model from TypeSafe AI.
Instead of asking an AI model to generate an explanation, an application can provide state and define the type of decision it needs.
Jev supports decision patterns such as:
- Choice – select one option from a predefined set
- Score – evaluate something on an ordered scale
- Noul – return a calibrated yes/no probability
The important concept is:
1
2
3
4
5
6
7
Application State
↓
Jev
↓
Structured Decision
↓
Application Logic
For example:
1
2
3
4
5
6
7
8
9
10
User Request:
"I want to reset my password."
Question:
Which workflow should handle this request?
Options:
- password-reset
- account-support
- security-review
Jev can return a structured decision that the application can use for routing.
Jev and AWS
Jev is currently not a native foundation model in the Amazon Bedrock model catalog. It does not use the same request/response interface as a typical generative model exposed through Bedrock's InvokeModel or Converse APIs.
Instead, Jev can be called as an external decision step from an AWS application or agent.
A simplified architecture looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
┌──────────────────┐
│ User │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ API Gateway │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ AWS Lambda │
│ Application │
│ Logic │
└───────┬──────────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
┌──────────────┐ ┌────────────────┐
│ Jev │ │ Amazon Bedrock │
│ Decision │ │ Generative AI │
│ Layer │ │ │
└──────┬───────┘ └───────┬────────┘
│ │
└──────────┬───────────┘
▼
┌─────────────────┐
│ Application │
│ Decision │
└─────────────────┘
The idea is not to replace Bedrock or an LLM.
Instead:
Jev can handle fast, bounded decisions while a generative model handles complex reasoning and content generation.
Example Use Case: AI Agent Tool-Risk Gate
Consider an AI coding agent running on AWS.
Before executing a command, the application can ask Jev to evaluate the proposed action.
For example:
1
2
3
4
5
6
7
An AI agent wants to execute:
rm -rf ./dist
aws s3 sync ./build s3://production-assets --delete
Context:
The command is part of a production deployment.
The application could ask:
1
2
3
4
5
6
7
8
Risk:
How risky is this operation?
Options:
1. safe
2. low
3. needs-review
4. high
It could also ask:
1
2
3
4
5
Production:
Does this action affect production?
Expected:
yes / no
And:
1
2
3
4
5
6
7
Action:
What should the agent do?
Options:
- allow
- confirm
- block
This creates a decision gate before the tool is executed.
A simplified flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
AI Agent
│
▼
Proposed Tool Call
│
▼
Jev Risk Check
│
├── allow ───────► Execute Tool
│
├── confirm ─────► Ask Human
│
└── block ───────► Stop Execution
This type of tool-risk gating is one of the documented Jev use cases.
Calling Jev from AWS Lambda
A practical implementation can use AWS Lambda as the backend.
The API key should never be placed directly inside frontend JavaScript or committed to GitHub.
Instead, store the credential securely and let Lambda access it.
A simplified Python example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
import os
import requests
JEV_API_KEY = os.environ["JEV_API_KEY"]
url = "https://jevai.info/v1/systemone"
payload = {
"model": "typesafe/jev-1.13",
"state": """
A production deployment command is about to execute.
The command deletes the existing build directory and
synchronizes a new build to an S3 production bucket.
""",
"questions": {
"risk": {
"type": "score",
"scale": [
"safe",
"low",
"needs-review",
"high"
]
},
"touches_production": {
"type": "noul"
},
"action": {
"type": "choice",
"options": [
"allow",
"confirm",
"block"
]
}
}
}
response = requests.post(
url,
headers={
"Authorization": f"Bearer {JEV_API_KEY}",
"Content-Type": "application/json"
},
json=payload,
timeout=10
)
print(response.json())
The exact API schema should be checked against the current Jev API documentation before deploying production code. The current developer documentation specifies the API base URL, authentication method, and model identifier.
Recommended AWS Architecture
For a production-oriented implementation, the following services can be combined:
Amazon API Gateway
Receives requests from the frontend or application.
AWS Lambda
Runs the application logic and communicates with Jev.
AWS Secrets Manager
Stores the Jev API credential securely.
Amazon CloudWatch
Collects logs and application metrics.
Amazon Bedrock
Handles tasks that require generative AI, reasoning, summarization, or content generation.
Amazon DynamoDB
Can store application state, decisions, or audit information when required.
A possible architecture is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Users
│
▼
Amazon API Gateway
│
▼
AWS Lambda
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Jev Amazon Bedrock
Decision Layer Generative AI
│ │
└─────────────┬─────────────┘
│
▼
Application
│
┌────────────┴────────────┐
▼ ▼
DynamoDB CloudWatch
Why Combine Jev and an LLM?
An AI application does not necessarily need one model to perform every task.
A useful architecture is:
1
2
3
4
5
6
7
8
9
10
11
User Request
│
▼
Jev
│
┌──────────┼──────────┐
▼ ▼ ▼
Route A Route B Human Review
│ │
▼ ▼
LLM/Agent LLM/Agent
For example, Jev can make a routing decision:
1
2
3
4
5
6
7
8
Customer Request
↓
Jev
↓
┌─────┴─────┐
│ │
Billing Technical
Agent Agent
The selected agent can then use Amazon Bedrock for the more complex conversational work.
AWS developer community material has also demonstrated Jev being used with AWS Strands for agent decision points and tool-call gating.
Security Considerations
When integrating an external AI API with AWS, security should be considered from the beginning.
1. Never hard-code API keys
Avoid:
1
JEV_API_KEY = "my-secret-key"
Use an AWS-managed secret instead.
2. Keep credentials server-side
The browser should communicate with your AWS backend.
1
2
3
4
5
6
7
8
9
10
Browser
│
▼
API Gateway
│
▼
Lambda
│
▼
Jev
The API key should never be exposed to the browser.
3. Use IAM least privilege
Lambda should receive only the permissions it actually requires.
4. Monitor requests
Use CloudWatch to monitor:
- Lambda errors
- latency
- request counts
- decision failures
- unexpected responses
5. Validate decisions
Jev returns structured decisions, but application developers should still validate outputs before allowing sensitive actions.
Important Difference: Jev vs Amazon Bedrock
Jev and Amazon Bedrock solve different parts of an AI architecture.
| Capability | Jev | Amazon Bedrock |
|---|---|---|
| Primary purpose | Structured decisions | Generative AI |
| Text generation | No | Yes |
| Classification | Yes | Yes |
| Routing | Yes | Possible |
| Probability/decision output | Core feature | Model-dependent |
| Long-form response | No | Yes |
| Agent reasoning | Decision layer | Can power agents |
| Native Bedrock foundation model | No | Yes |
Therefore, the goal should not necessarily be:
1
Jev OR Bedrock
A more useful architecture can be:
1
Jev + Bedrock
where each component performs the task it is designed for.
Conclusion
Jev introduces an interesting pattern for AI application architecture: separating fast decisions from deep generative reasoning.
On AWS, developers can use Jev as an external decision layer while using services such as Lambda, API Gateway, CloudWatch, DynamoDB, and Amazon Bedrock around it.
A simple mental model is:
1
2
3
Jev = Decide
LLM = Reason + Generate
AWS = Build + Run + Secure + Monitor
This approach can be particularly useful for:
- AI agent routing
- tool-call safety gates
- request classification
- human-review workflows
- automated decision systems
- model routing
- low-latency application decisions
As with any AI decision system, production deployments should validate model behavior against representative test cases and maintain appropriate application-level safeguards.
References
- Jev API documentation
- AWS Developer Community discussions on Jev
- Amazon Bedrock documentation
- AWS Lambda documentation
- AWS Strands documentation
Jev's current API documentation is available from the Jev developer guide, while AWS community material documents patterns for combining Jev with agent workflows.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article