DEV Community: AK

Scheduled Tasks in Agent Kernel: Work That Runs Without Anyone Asking

AK — Tue, 06 Oct 2026 11:09:02 +0000

Imagine hiring a brilliant assistant who never speaks unless spoken to.

Ask them anything and you get a thoughtful answer in seconds. But say "remind me about this on Monday" and they just stare back. No calendar. No alarm clock. No way to act unless you are standing there.

That is every AI agent today. Agents are excellent at answering. The other half of real work is the part nobody is around to ask for: the 8am summary, the Monday report, the follow-up three days from now.

Agent Kernel gives your agent a clock.

An Agent That Works While You Sleep

Look at the day above again. Five pieces of work happened. Nobody sent a single message to start any of them.

That is the entire shift. Your agent stops being something your team has to operate and starts being something that simply runs — the overnight digest waiting when the first person logs on, the lead that gets chased on the day it was worth chasing, the Friday report nobody has to remember to ask for.

And crucially, you do not build a second system to get this. No cron container. No scheduling microservice. No Lambda glued to the side of your agent, no second deployment pipeline, no second thing to page someone at 3am. Scheduling is a setting, not a project.

Just Ask. In Plain English.

Here is the part that changes who gets to use this.

Your users do not file a ticket. They do not learn cron syntax. They do not wait for an engineer. They just say what they want, the way they would say it to a colleague:

curl -X POST http://localhost:8000/api/v1/chat \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Every weekday at 8am in Asia/Colombo, remind me to review the overnight alerts.",
       "session_id": "ses-3", "user_id": "alice"}'

That is not a special scheduling endpoint. It is an ordinary message. The agent reads the intent, works out the rhythm, and books it — then tells the user it is done.

Turn scheduling on and every agent quietly gains the ability to manage its own calendar of work: creating a schedule, listing what it has booked, amending a time, pausing something, cancelling it outright. You write no tool descriptions and no glue code. Your agent's instructions never mention scheduling at all.

Which means the capability arrives for the people who actually needed it — the ops lead, the account manager, the analyst — without any of them going through engineering first.

What Teams Are Using It For

Reminders and nudges for real people. The agent books work on someone's behalf and handles it when the time comes. "Check in with me about this on Monday." "Every weekday at 8am." The kind of thing a good assistant does without being reminded to.

Recurring reporting. Overnight alert digests, Monday morning summaries, the Friday wrap-up. Work that always happened on a rhythm and always depended on a human remembering to kick it off.

Customer follow-ups. Chase a lead in three days. Revisit a ticket that has gone quiet. Flag a renewal before it lapses. The follow-ups that slip through are the ones nobody scheduled.

Unattended operations. Nightly data-quality sweeps, scheduled health checks, cleanup that runs and writes up what it found. The agent does the pass and leaves you the summary.

Nothing Gets a Second-Class Path

Here is the design decision underneath all of it: the agent never finds out it was scheduled.

A run that fires at 3am is, as far as the runtime is concerned, indistinguishable from a person typing at 3pm. So every guardrail you configured still applies. Every safety check still runs. Tracing, logging, memory, tools — all of it behaves exactly as it does live, because to the system it is live.

This matters more than it sounds. Bolt-on schedulers tend to create a quieter, less supervised back door into your agent, precisely at the hours when nobody is watching. There is no such door here. Your agent code needs no scheduling branch, because it has no way to detect one.

Nothing happens in the dark, either. Every scheduled task belongs to a specific user, every run is traceable back to the task that produced it, and cancelling something keeps the record — so the history of what was scheduled, and by whom, survives.

From Your Laptop to Production

Start on a laptop with everything running inside a single process, nothing to stand up. When you go to production on AWS, managed timers and durable storage take over, so nothing is forgotten when a container restarts.

The application code is byte-for-byte identical between the two. Only the configuration moves.

The Bottom Line

Scheduling is the difference between an agent that responds and an agent that operates.

One waits to be asked. The other shows up on Monday with the report already written, because someone mentioned it once, in passing, three weeks ago.

Your assistant finally has a calendar.

Agent Kernel is open source under Apache 2.0.

Scheduling documentation: https://kernel.yaala.ai/docs/advanced/scheduling
Runnable example: examples/api/schedule-openai
On AWS: examples/aws-containerized/openai-schedule · examples/aws-serverless/schedule-openai
GitHub: https://github.com/yaalalabs/agent-kernel

pip install "agentkernel[cron]" and give your agents a clock.

Originally published at kernel.yaala.ai on September 14, 2026.

Your Cluster, Your Data, One Helm Chart: Agent Kernel on On-Prem Kubernetes

AK — Tue, 06 Oct 2026 11:01:45 +0000

By Yaala Labs

Some workloads are never leaving the building.

Patient records. Trade surveillance feeds. Customer data that a regulator, a sovereign-cloud mandate, or a signed contract says must stay on hardware you control. The teams responsible for that data are also, very often, the teams that already run Kubernetes: a platform group with a cluster, a GitOps pipeline, an on-call rota, and a firm opinion about anything that tries to route around them.

Until now, Agent Kernel met those teams halfway. The Terraform modules for AWS, Azure, and GCP take an agent from laptop to production in one apply, but on-prem meant a Docker image and a set of environment variables, with the topology left as an exercise. That gap is closed. Agent Kernel now ships an official Helm chart that deploys the full queue-execution pipeline to any Kubernetes cluster running 1.29 or later: bare metal in your data center, a managed EKS cluster, or a k3d cluster on your laptop. The chart is published as an OCI artifact with every release, versioned like the Python package, and your agent code does not change by a single line. Air-gapped clusters are supported out of the box, and the same chart ships a sandbox broker tier, so the code your agents write runs in sandboxed pods inside your cluster too.

Why This Matters

Data residency stops being a blocker. The agents, the broker, the session store, and the sandbox all run inside your cluster. Nothing in the pipeline needs a managed cloud service.
Your platform team stays in charge. The chart plugs into what they already run: Gateway API for ingress, cert-manager for certificates, KEDA for autoscaling, Prometheus for metrics. It deliberately installs none of those prerequisites itself, so nothing lands on the cluster behind their backs.
It is the same pipeline you would run on AWS. Per-session ordering, bounded retries, deduplication, graceful failure replies: identical semantics, because the transport is configuration, not code.
A quiet Tuesday and a busy Saturday need different fleets. The agent tier scales on queue depth, the signal that actually tracks LLM-bound work, instead of CPU, which sits idle while requests back up.
Air gaps are a first-class case. Two registry values (one for the application images and Valkey, one for the NATS subchart) and a per-release image manifest are all a disconnected cluster needs.

The Same Pipeline, Now in Pods

If you read the AWS queue-mode post, the shape will look familiar. Every chat request still travels the five-stage path:

Request Handler → Input Queue → Agent Runner → Output Queue → Response Handler

On Kubernetes the chart splits those stages across two Deployments, with a third one optional:

Deployment	What it runs
`io-handler`	The REST API (Request Handler) and the Response Handler that reads replies back off the output queue
`agent-runner`	The consumers that execute your agents: LLM calls, tools, retries
`ws-gateway` (optional)	WebSocket delivery for the `async` and `stream` execution modes

Traffic enters through a Gateway API HTTPRoute, REST to the io-handler and WebSocket to the gateway. Valkey holds responses and sessions, NATS JetStream is the default broker, and both ship as condition-gated dependencies of their official charts, so a dev cluster gets them for free and a production cluster can point at the instances it already operates.

Your Images, the Chart's Wiring

The chart runs your images. Your config.yaml, baked into the image, declares what runs: which agents, which framework, which execution mode. The chart injects where it runs as AK_* environment variables. It is the same application and infrastructure split the ECS Terraform deployment uses, so an image built for one feels familiar on the other.

Each image has a one-line entry point:

Image	Entry point
io-handler	`IOHandler.run()`
agent-runner	register your agent modules, then `AgentRunner.run()`
ws-gateway	`WebSocketGateway.run(auth_validator=...)`

The end-to-end example builds all three from python:3.12-slim and walks the deployment on k3d, microk8s, and k3s. Kubernetes is not even required to exercise the wire behavior: the same pipeline runs as two local processes over docker compose under examples/transport/nats.

Three Flavors, Zero Forked Templates

Deployment flavors are values files over one set of templates. Every difference between a laptop and a data center is a value, never a fork.

Values file	Posture
`values-dev.yaml`	Micro-clusters (k3d, kind, microk8s, k3s): single replicas, auto-provisioned JetStream, TLS off, port-forward entry. The smallest profile is one pod with in-process queues and no backing services at all.
`values-baremetal.yaml`	Envoy Gateway class, cert-manager issuer annotations, NACK-managed JetStream objects, OpenEBS hostpath storage, MetalLB as the load balancer.
`values-eks.yaml`	AWS Load Balancer Controller gateway classes, ACM certificates, EBS gp3 storage, Pod Identity. `nats`, `kafka`, and `sqs` are all valid brokers here.

The flavor files ship inside the chart, which is what helm pull --untar unpacks, so the values you start from always match the chart version you installed.

Pick Your Broker

transport.type selects the broker. The pipeline semantics do not move:

nats, the default and the recommendation on-prem. JetStream work-queue streams with one durable consumer per partition. Dev clusters auto-provision the streams at startup; production manages them declaratively through the chart's NACK custom resources and fails loudly if an object is missing, rather than creating one on the fly.
kafka, paired with the Strimzi operator. The chart renders the Kafka cluster, its node pool, and the topics as Strimzi resources, so the broker is part of the same release as the application.
sqs, for EKS. No broker to operate at all: pods authenticate through Pod Identity and the queues live in AWS.

Whichever you choose, a conversation's turns stay in order, a crashed runner leaves the turn on the queue for the next one, a retried request is not enqueued twice, and a turn that exhausts its retries produces a graceful error reply instead of a silent hang.

WebSockets That Survive a Rollout

Streaming and push delivery are where most Kubernetes deployments of chat systems get awkward, because a socket is pinned to a pod and pods are disposable. The chart's ws-gateway tier is built around that fact instead of against it.

Gateway pods own the client sockets and enqueue chat frames directly onto the transport. When the Response Handler has a reply, or a single streamed token chunk, it looks up which gateway pod holds that user's connections in a shared connection store on the session backend and pushes to an authenticated internal endpoint on that pod. Replies reach every connection a user has open, on whichever pod holds it. Because the io-handler and agent-runner pods are never on the socket path, they can roll, scale, or crash without dropping a single connection.

Scaling on the Signal That Matters

An agent turn is I/O-bound. The runner spends most of its life waiting on a model provider while requests pile up behind it, so CPU utilisation is the one metric that tells you nothing. The agent-runner tier therefore scales on queue depth through KEDA: Kafka consumer lag, NATS JetStream pending messages, or SQS queue length, chosen automatically by the transport you configured.

Two guardrails are baked into the defaults. minReplicaCount is 1, because a runner cold start (image pull plus Python imports) is slow enough that scaling from zero would hurt the first customer of the morning. For the NATS and Kafka transports, maxReplicaCount defaults to the partition count divided by consumers per pod, since past that point a new replica finds no free partition to claim; for SQS it defaults to 10. The io-handler tier, which is request-bound, scales on plain CPU.

Scaling down is as careful as scaling up. Runners observe SIGTERM, stop claiming work, and finish their in-flight turns within terminationGracePeriodSeconds, which defaults to two minutes and should exceed your longest agent turn.

A Sandbox Worker Tier, Inside the Same Chart

If your agents run code through the Execution Broker, the chart also deploys the queue-backed sandbox worker. Enable sandboxWorker and a third consumer tier appears: it takes sandbox execution requests off their own queues on the same transport, runs each one through a sandbox provider (typically the kubernetes provider, one pod per sandbox, running as a ServiceAccount the chart binds to nothing, so the RBAC you grant it is the security boundary), and returns completions into the shared response store. The tier brings its own ServiceAccount and RBAC, KEDA scaling on the sandbox backlog, and values-gated namespace hardening: Pod Security Admission, default-deny egress, and resource quotas.

It also installs standalone. If your agents run in Lambda or ECS but code execution has to happen inside your own cluster, disable ioHandler and agentRunner, and the chart deploys only the sandbox worker. The agent side and the worker then meet solely on the shared sandbox queues and response store.

Built for Air Gaps

Disconnected clusters get two things. global.imageRegistry prefixes the application images and the Valkey subchart's; the NATS subchart reads global.image.registry instead, so set both and every image the chart renders comes from your private registry. And every release attaches an images.txt manifest listing those images for mirroring, generated by templating every flavor with every optional tier enabled. One exception: on the Kafka flavor the Strimzi operator pulls the broker images itself, so they are mirrored and configured through Strimzi, not this chart. The chart itself is an OCI artifact, so it copies into the same registry and installs by digest from there.

Observability Without Surprises

Metrics and tracing ship as documented recipes rather than chart dependencies: a kube-prometheus-stack install, exporters for whichever broker you chose, and an OpenTelemetry Collector funnel that feeds the Langfuse, OpenLLMetry, and Pydantic Logfire tracing providers Agent Kernel already supports. Your existing monitoring stack keeps its job.

Get Started

You need Helm 3.14 or newer (Helm 4 works too), a cluster on Kubernetes 1.29 or later, and your application images loaded where the cluster can pull them.

helm pull oci://ghcr.io/yaalalabs/charts/agent-kernel --untar   # unpacks the flavor values files
helm install ak oci://ghcr.io/yaalalabs/charts/agent-kernel \
  -f agent-kernel/values-dev.yaml \
  --set ioHandler.image.repository=<io image> \
  --set agentRunner.image.repository=<runner image> --set image.tag=<tag>

kubectl port-forward service/ak-agent-kernel-io 8000:80
curl -s -X POST http://localhost:8000/api/v1/chat \
  -H 'Content-Type: application/json' \
  -d '{"prompt": "Hello", "session_id": "s1", "agent": "triage"}'

Without a --version flag Helm resolves the latest published chart; add one to pin a release, and the deployment guide always shows the current pinned command. One thing to know when you find the chart on GitHub: the package page shows a docker pull command, because GitHub renders that box for every artifact in its container registry. Charts are installed with helm, as above.

Agent Kernel is open source under Apache 2.0.

On-Prem / Kubernetes deployment guide: https://kernel.yaala.ai/docs/deployment/onprem-kubernetes
Chart README, with values, prerequisites, and flavors: https://github.com/yaalalabs/agent-kernel/tree/develop/ak-deployment/ak-k8s
End-to-end example on k3d, microk8s, and k3s: https://github.com/yaalalabs/agent-kernel/tree/develop/examples/k8s/openai-queue-mode
The chart on GHCR: https://github.com/yaalalabs/agent-kernel/pkgs/container/charts%2Fagent-kernel
Queue Mode Guide: https://kernel.yaala.ai/docs/advanced/queue-mode-guide

helm install it on the cluster you already trust, and let the agents come to the data instead of the other way round.

Originally published at kernel.yaala.ai on September 14, 2026.

Scaling Agent Kernel on AWS: Decoupling Request Handling from Agent Execution

AK — Tue, 06 Oct 2026 10:59:59 +0000

By L. I. Kumara

A busy restaurant never asks the person taking your order to also cook your meal.

Taking an order is fast: hear it, write it down, hand it off. Cooking is slow, and how long it takes depends on what was ordered and how many pans are free. Bundle both jobs into one role and a quiet Tuesday hides the problem completely — but on a packed Saturday night, the whole restaurant grinds to a halt, because the person taking orders is stuck at the stove.

AI agents have exactly this problem. Answering an HTTP request is cheap and instant. Running an agent turn is not — it can chain several LLM calls, wait on tools, and take anywhere from a second to several minutes. Most teams build both into the same service, so the fast part and the slow part are forced to scale together, sized for whichever one is heavier that day. Agent Kernel now ships the fix as a configuration switch: a durable queue between request handling and agent execution on AWS, for both Lambda and ECS, with zero changes to your agent code.

Why This Matters, Before the How

Strip away the infrastructure talk and this is a customer-experience and cost problem:

Your busiest moments stop being your riskiest ones. A traffic spike lengthens a queue instead of piling every request onto your AI model provider at once — no dropped connections, no cascading timeouts right when the most customers are watching.
You stop paying to guess. Request handling and agent execution scale independently, so you're no longer over-provisioning the fast, cheap part just to keep up with the slow, expensive part.
A crash doesn't cost you a conversation. If something dies mid-turn, the request simply waits for the next available worker instead of vanishing.
A customer's message never gets answered twice, even if their app retries a request or they double-click "send."
A conversation stays in order, even when hundreds of other customers' conversations are running through the system at the same time.

None of this requires touching your agent's logic. It's a deployment setting, not a rewrite.

Where the Simple Setup Runs Out of Road

Agent Kernel's own deployment docs are direct about the tradeoff: the simplest AWS setup — one ECS service, or one Lambda function, handling both the REST API and the full agent turn — is scoped for "moderate traffic, simplest setup." Getting to "high throughput, long-running agents, backpressure control" means putting a queue between the two.

When request intake and agent execution share a container or a Lambda invocation, there's also nothing standing between the caller and the model provider. Without a queue to absorb a burst, request volume maps straight onto provider call volume: a spike in traffic is a spike in simultaneous provider calls, with nothing capping how hard the provider gets hit or smoothing the burst into a manageable rate. That's a fine trade at steady, moderate traffic. It stops being fine the moment concurrent long-running turns arrive in bursts — which is exactly when scaling matters most.

Putting a Queue in the Middle

The fix is unglamorous and well-worn: put a durable queue between the caller and the agent. Every chat request now travels a fixed five-stage path:

Request Handler → Input Queue → Agent Runner → Output Queue → Response Handler

The queue transport and the process topology are chosen entirely by configuration, not by rewriting agent code. Locally, all five stages run as threads inside one process against an in-memory transport, so the exact same pipeline semantics — per-session ordering, bounded retry, deduplication — are testable on a laptop. On AWS, the queues become durable SQS FIFO queues, and the stages split across Lambda functions or ECS services depending on which deployment you pick.

Splitting the pipeline this way buys you several things at once:

Independent scaling — the request/response path and the Agent Runner pool scale on their own curves instead of being sized as one unit.
Backpressure — a traffic spike lengthens the queue instead of fanning out into a pile of simultaneous provider calls.
Per-session ordering — MessageGroupId = session_id keeps a conversation's turns strictly in order while unrelated sessions process fully in parallel.
Crash resilience — a message only leaves the queue once it's fully processed, so a worker crashing or hanging mid-turn simply leaves the turn there for the next worker.
Automatic bounded retries — unacknowledged messages redeliver up to max_receive_count, absorbing provider rate limits and transient failures without the caller noticing. After that, the caller gets a graceful error instead of a hang.
Deduplication — MessageDeduplicationId = request_id means a caller-retried request isn't enqueued twice, and the Agent Runner's reply isn't delivered twice — but only inside SQS FIFO's 5-minute dedup window. A caller retrying later than that, or a stream-mode chunk (whose dedup ID deliberately includes the receive count), gets through, so delivery stays at-least-once end to end and anything with side effects should be idempotent on request_id. (Redelivery after a processed-but-unacknowledged failure is a separate thing: that's the retry bullet above doing its job.)

None of this is exotic. What matters is that Agent Kernel now gives it to you as a configuration switch rather than infrastructure you build yourself.

Two Deployment Shapes, One Pipeline

Lambda: Scaling You Don't Have to Configure

On Lambda, the five stages map to three functions. A Request Handler enqueues onto the Input SQS FIFO queue with the session ID as the message group. An Event Source Mapping triggers the Agent Runner Lambda, which runs the agent and writes the reply to the Output Queue, reporting partial failures via batchItemFailures so only the messages that actually failed come back for retry. A second ESM triggers the Response Handler, which writes the result to DynamoDB (rest_sync/rest_async) or pushes it straight over a WebSocket connection (async/stream).

The appeal here is that Lambda scales the Agent Runner 1:1 with queue batches automatically. There's no scaling policy to write and no capacity to plan for; concurrency grows and shrinks with the backlog on its own.

ECS: Long-Running Services, Explicit Scaling

ECS trades Lambda's zero-config scaling for containers that stay warm, which matters for consistent latency and workloads that don't fit serverless limits well. The same five stages become two services: an IO container running a REST/WebSocket API thread alongside an Output Queue consumer thread, and an Agent Runner service whose threads long-poll the Input Queue directly. Both are internally multi-threaded — five input consumers and two output consumers by default — so a single container is already handling several sessions concurrently before the ECS service itself scales out.

Because ECS doesn't get Lambda's built-in batch-triggered scaling, it needs an explicit policy. CPU and memory are a poor proxy here: agent workloads are I/O-bound, waiting on the model provider, not burning CPU. So the Agent Runner scales on backlog per task instead: a scheduled Lambda reads the Input Queue depth every minute, divides it by the running task count, and publishes the result as a custom CloudWatch metric. An ECS Target Tracking policy then holds that number at or below a target you set:

scaling_config = {
  enabled            = true
  min_count          = 1
  max_count          = 10
  backlog_target     = 5
  scale_in_cooldown  = 180
  scale_out_cooldown = 60
}

backlog_target is the one knob that matters: a lower value (1-2) keeps latency tight by scaling out aggressively; a higher value (5-10) trades some queue depth for cost efficiency. It's also possible to scale the Agent Runner to zero (min_count = 0) for spiky or infrequent workloads, letting the fleet park at no cost between bursts.

The Same Guarantee, Delivered Four Ways

Every one of the four client communication modes — REST Sync, REST Async (poll), Streaming (SSE/WebSocket chunks), and Async (WebSocket push) — rides the identical Input Queue → Agent Runner → Output Queue shape. Only the last hop changes: rest_sync/rest_async land in a DynamoDB response store the caller reads back from; async/stream skip the database entirely and push straight down an open WebSocket connection, one message per full reply or one per streamed token chunk. Nothing about the queue contract, the retry semantics, or the ordering guarantee changes based on which mode a client is using.

One safety detail worth calling out: the app-level max_receive_count is deliberately set one below the SQS redrive policy's maxReceiveCount. That way, on the final retry, Agent Kernel writes a graceful error to the response store before SQS quietly moves the message to a dead-letter queue, so an HTTP caller never sits there waiting on a reply that's already been given up on.

Config In, Not Code Change

Turning this on is a Terraform flag, not an agent rewrite:

queue_mode     = true
execution_mode = "rest_sync"   # or rest_async | async | stream

The yaalalabs/ak-containerized/aws and yaalalabs/ak-serverless/aws Terraform modules provision the queues, IAM policies, response store, and (for ECS) the scaling stack automatically. Your agent definitions never reference a queue, a consumer thread, or a retry count — they run exactly as they do against the in-memory transport on your laptop.

What's Next

SQS + Lambda and SQS + ECS validate a shape that generalizes: input queue, independently-scaling runner, output queue, pluggable response delivery. That same contract now also ships as a Kafka transport (pip install agentkernel[kafka]) and a NATS JetStream transport (pip install agentkernel[nats]) for on-premise and self-hosted deployments, with the identical per-session ordering, dedup, and bounded-retry semantics, just backed by partitions and consumer groups (or JetStream work-queue streams) instead of SQS FIFO queues. Both come with runnable two-process local examples under examples/transport/. A Kubernetes-native topology (Helm charts, KEDA autoscaling) is next, so the scaling model here isn't tied to one cloud, or to AWS at all.

Get Started

Agent Kernel is open source under Apache 2.0.

Queue Mode Guide: https://kernel.yaala.ai/docs/advanced/queue-mode-guide
AWS Containerized Deployment: https://kernel.yaala.ai/docs/deployment/aws-containerized
GitHub: https://github.com/yaalalabs/agent-kernel

pip install agentkernel and let the queue absorb your next traffic spike instead of your Agent Runner.

Originally published at kernel.yaala.ai on August 17, 2026.

Introducing the Agent Kernel Execution Broker: A Safe Place for AI Agents to Run Code

AK — Tue, 06 Oct 2026 10:49:59 +0000

By Yaala Labs

AI agents have become remarkably good at writing code. Running that code is where most teams stop.

And they are right to hesitate. An agent that can execute code on your infrastructure can also read your filesystem, call your internal APIs, exhaust your CPU, or exfiltrate data over the network. So teams end up in one of two places: they switch code execution off entirely and cap what their agents can do, or they build a one-off sandbox stack in-house, wire it to one agent framework, marry it to one vendor, and maintain it forever.

The Agent Kernel Execution Broker removes that trade-off. It is a vendor-neutral brokering layer that sits between your agents and the environments their code runs in, with security policy and access control enforced on every single execution.

One Broker Between Agents and Every Sandbox

The idea is simple. Agents never touch execution backends directly. They ask, and the Execution Broker routes the request to an isolated sandbox through a pluggable provider.

Enable it, and every agent gains code, shell, and file tools automatically, with usage guidance injected into its instructions. Your agent code never mentions the sandbox at all.

Before any code runs, two gates are checked, and both fail closed:

Security policy. Each execution runs inside a permission and resource envelope: network egress rules (allow, deny, or an allowlist), filesystem read and write scopes, CPU and memory limits, and a hard wall-clock timeout. If a backend cannot enforce a policy you asked for, the execution is rejected rather than silently downgraded. Security is never quietly weakened to make something run.
Access control and identity. Sandboxed code can run under the agent's identity or under the authenticated end user's identity, resolved per session. A user-scoped request can never silently fall back to broader agent credentials.

That fail-closed posture is the heart of the design: the broker checks what a backend has honestly declared it can enforce, and refuses anything it cannot guarantee.

Your Containers, Your Rules

For teams that want full control, Docker mode lets you bring your own curated container images as the sandbox environment. Your golden image, your internal registry, your approved dependencies, your compliance checklist baked in. The broker adds enforced isolation on top: network switched off or restricted, CPU and memory capped, a read-only root filesystem with a writable workspace.

Security teams get a controlled, auditable execution surface. Agents get a fully equipped environment. Nobody has to choose.

An honest note on where responsibility sits today: command-level security comes from the environment you bring. Your curated container decides which interpreters, binaries, and tools exist for the agent to invoke, which is exactly where that control belongs. And this layer is about to get deeper: in the next version, sandbox providers gain native pseudo-terminal support, bringing full PTY sessions to Daytona, E2B, and other connections.

Connect to Systems You Already Own

Not every workload belongs in a disposable sandbox. Sometimes the agent needs to operate on a real machine: an EC2 instance running your batch jobs, a long-lived container with your tooling installed.

The broker supports this through attached environments, and it treats them with the respect your infrastructure deserves. Attaching is an explicit, validated opt-in in configuration, never a side effect. The broker connects to the environment but never owns it: it will not provision it, will not destroy it, and will never silently recreate it if it becomes unreachable. Pointing agents at a live system is a deliberate decision, and the framework enforces that.

Five Providers Out of the Box

The Execution Broker ships with pre-built providers, each honestly declaring its isolation tier:

Local Subprocess, no isolation. Runs on the host for development and testing only.
Docker, container isolation. A container per sandbox on your own Docker daemon, with network, filesystem, and resource policy actually enforced.
E2B, micro-VM isolation. Managed Firecracker micro-VMs in the E2B cloud, with a stateful kernel where variables persist across calls.
Daytona, container isolation. Managed cloud container sandboxes with enforced network and resource policy, plus warm starts from snapshots.
EC2 via SSM, attach-only with no added isolation boundary, because it runs on an instance you already own. Supports running commands as a specific user through AWS role assumption.

Those tiers are part of the contract. The framework never pretends two backends are interchangeable on security grounds; you always know exactly what boundary you are getting.

Sessions and a Lifecycle You Never Manage

Real work is rarely one command. An agent writes a script, runs it, inspects the output, fixes a bug, and runs it again. The broker makes this natural through sandbox sessions: each session is a persistent workspace, so files written in one step are still there several conversation turns later. Sessions are isolated per conversation, and agents can create, list, and discard them as easily as calling a tool.

You choose the lifetime per workload: a persistent workspace for multi-step projects, a fresh throwaway sandbox per call for stateless computation, or a shared warm environment when startup cost matters.

The lifecycle runs itself. Idle sandboxes are reclaimed automatically and recreated on the next touch. If a backend sandbox vanishes, the broker heals the session under the same identity, and, crucially, tells the agent that the workspace was reset. Nothing is ever swept under the rug. Long-running executions do not block the conversation either: they are promoted to background tasks the agent polls, so a twenty-minute job and a two-second one flow through the same tools.

Nobody on your team writes provisioning, cleanup, or reconnection code. Ever.

Framework-Neutral, Plug and Play

Here is the part that changes the dynamic.

Everything above works with whatever agent framework you already use: OpenAI Agents SDK, LangGraph, CrewAI, Google ADK, Smolagents, Pydantic AI. The sandbox capability is switched on with a few lines of configuration, and switching providers is a configuration change, not a rewrite. Develop against local subprocesses, test against Docker, ship on micro-VMs, and your agents never know the difference.

The industry keeps offering the same deal: adopt our sandbox, adopt our SDK, adopt our lock-in. Agent Kernel takes the opposite position. The broker is the contract; providers are interchangeable plumbing. Your security policy, your identity model, your session semantics, and your agent code all stay put while the execution backend underneath is swapped freely.

And when none of the built-in providers fit, you bring your own. Implement the provider interface for your internal platform, your Kubernetes setup, your private cloud, and point the configuration at it. A public contract test suite verifies your implementation honors the same semantics. Your custom backend instantly inherits everything the broker provides: policy enforcement, identity, sessions, self-healing lifecycle, background task promotion. You write the connection to your infrastructure; Agent Kernel supplies the guarantees.

This is what plug and play looks like in practice. The sandbox is switched on in configuration:

config.yaml

sandbox:
  enabled: true
  type: docker              # or e2b | daytona
  docker:
    image: python:3.12-slim
  broker:
    flavor: thread

And the agent code never mentions the sandbox at all:

demo.py

from agents import Agent
from agentkernel.cli import CLI
from agentkernel.openai import OpenAIModule

coder = Agent(
    name="coder",
    instructions="You are a coding assistant.",
)

OpenAIModule([coder])

if __name__ == "__main__":
    CLI.main()

Swap docker for e2b, daytona, ec2_ssm, or your own provider. The agent never knows the difference.

The Bottom Line

Code execution is the capability that turns AI agents from advisors into operators, and it is exactly the capability most enterprises cannot responsibly turn on without guardrails. The Agent Kernel Execution Broker makes it safe to say yes: one broker, guarded by fail-closed security policy and access control, in front of any sandbox you choose, with none of your agent code held hostage by the choice.

Agent Kernel is open source under Apache 2.0.

Sandbox documentation: https://kernel.yaala.ai/docs/advanced/sandbox
Architecture deep dive: https://kernel.yaala.ai/docs/architecture/sandbox-internals
GitHub: https://github.com/yaalalabs/agent-kernel

pip install agentkernel and give your agents a safe place to run.

Originally published at kernel.yaala.ai on August 6, 2026.

Agent Kernel Now Runs on GCP - AWS, Azure, GCP, On-Prem. One Platform.

AK — Tue, 06 Oct 2026 10:47:46 +0000

By Yaala Labs

AWS. Azure. GCP. On-Prem. One platform. No rewrites. No lock-in.

Agent Kernel now ships full Google Cloud Platform support, completing the trifecta of major public clouds. Your agents now deploy identically across every environment, same observability pipeline, same compliance primitives, zero code changes.

What's Included

Built on Cloud Run, with two modes controlled by a single parameter:

Serverless - scale-to-zero serverless. No idle cost.
Containerized - always-on with zero cold starts.

Both are fully provisioned by Terraform: Artifact Registry, API Gateway + JWT auth, Firestore for session state, Memorystore for shared cache, and VPC isolation.

The Runtime That Takes Agents to Production

Getting an AI agent running is the easy part. Getting it running reliably in production, with proper auth, compliance guardrails, observability, and scalable infrastructure, is where the real work begins.

Agent Kernel is the runtime that handles all of it. You bring the agent logic; Agent Kernel brings everything required to make it production-grade: framework support (OpenAI Agents SDK, LangGraph, CrewAI, Google ADK etc.), cloud infrastructure via Terraform, built-in PII detection and audit traces, and full tracing on every LLM call and tool invocation through LangFuse and OpenLLMetry or bring-your-own.

The result is that shipping an agent to production feels like shipping any other service. No bespoke infrastructure work, no compliance bolt-ons, no cloud-specific rewrites. Just deploy.

Agent Kernel is the only agent operating system that offers true cloud-agnostic deployment across all three major public clouds and on-premises infrastructure. That's not a coincidence of timing; it's a direct outcome of Agent Kernel's adapter architecture. Every cloud provider, every AI framework, every LLM, and every tool integration is wired in through a clean adapter layer. Adding a new cloud is a new adapter, not a rewrite. This is what future-proofs AI companies: as the landscape shifts, new models emerge, and infrastructure requirements evolve, Agent Kernel extends without breaking what already runs in production.

The Full Picture

	AWS	Azure	GCP	On-Prem
Serverless	Lambda	Functions	Cloud Run	-
Containerized	ECS Fargate	Container Apps	Cloud Run	Docker / K8s
Session Store	DynamoDB	Cosmos DB	Firestore	Redis
IaC	Terraform	Terraform	Terraform	Terraform

Same agent code. Every cloud. That's the point.

Get Started

module "agent_kernel_gcp" {
  source  = "yaalalabs/ak-serverless/google"
  version = "0.5.1"

}

Ready to deploy?

See the GCP Serverless or GCP Containerized deployment guides.

Originally published at kernel.yaala.ai on June 9, 2026.

Agent Kernel Is Live at Climate Impact X

AK — Tue, 06 Oct 2026 10:44:27 +0000

By Yaala Labs

Climate Impact X (CIX), a leading exchange for environmental products such as carbon credits and renewable energy certificates, is now live with Agent Kernel as part of its trade surveillance workflow.

Production milestone

This marks an important production milestone: bringing AI-augmented surveillance into a real market environment where trust, fairness, and auditability are key.

An agentic workflow powered by Agent Kernel adds deeper insights and uncovers hidden patterns beyond traditional rule-based alerts. AI agents can review potential issues with speed and confidence, supported by clear, structured, investigation-ready context.

Agent Kernel provided the enterprise foundation to make that possible in production.

From Complexity to Production in Weeks

Building AI agents for production systems is usually not limited by model capability. Most delays come from engineering the surrounding platform requirements:

Scalable cloud deployment
Durable state across multi-step workflows
Strong operational guardrails
End-to-end observability and traceability
Reliable tool integration and orchestration
Behavior-focused testing

With Agent Kernel, those platform capabilities are already available. That allowed our team to focus implementation effort on exchange-specific surveillance logic and business requirements, not foundational infrastructure.

The result was an extremely fast production rollout.

What Agent Kernel Enabled

This implementation demonstrates the practical value of Agent Kernel's enterprise features:

Production-grade multi-agent orchestration
Serverless-first deployment patterns for variable workload traffic
Durable session and workflow state management
Policy guardrails for regulated environments
Audit-ready tracing and observability
Extensible tooling for enterprise data and workflow integrations
Testing support for validating agent behavior in realistic scenarios

Together, these capabilities reduce time-to-production while preserving the controls expected in high-trust systems.

From prototype to production

For teams evaluating how to move AI agents from prototype to production, this launch shows what is possible when the platform layer is already solved.

Originally published at kernel.yaala.ai on May 27, 2026.

Knowledge Bases: The Missing Layer That Lets AI Agents Self-Evolve

AK — Tue, 06 Oct 2026 10:40:46 +0000

By Yaala Labs

Most AI agents have a fundamental flaw: they forget everything.

Every conversation starts from zero. The agent doesn't remember that it got a fact wrong last Tuesday. It doesn't remember the new product line you told it about. It doesn't remember that a customer is a high-value account who hates upsells. It doesn't even remember its own mistakes.

That's not an AI agent. That's a very expensive autocomplete that resets every session.

Agent Kernel's Knowledge Base layer changes this completely. And more importantly — it gives agents something they've never had before: the ability to learn from their own operation and get measurably smarter over time.

What's Actually Wrong with Today's AI Agents

Let's be direct about the problem.

Current agent architectures give you session memory — what was said in this conversation — and that's about it. When the session ends, that memory is gone. The next user, the next session, the next agent instance starts fresh. Every piece of operational knowledge your agent accumulates evaporates when the conversation closes.

This creates a ceiling. Your agents plateau. They never improve from experience. They repeat the same mistakes. They rediscover the same domain knowledge on every call. And if you want them to know something new, you're back to prompt engineering, fine-tuning, or rebuilding the whole system.

There is a better architecture. And it's been sitting in front of us the whole time.

Durable Knowledge: The Layer Below Sessions

Agent Kernel draws a sharp line between two kinds of memory:

Session memory is volatile and scoped to one conversation. When the session ends, it's gone. This is the right place for things like: what the user said three messages ago, the partial result of a multi-step tool call, or a temporary calculation.

Knowledge bases are durable and cross-session. They persist between conversations, across agent instances, across deployments. This is the right place for: domain facts, learned corrections, customer profiles, product catalogs, operational patterns, and anything the agent should remember forever.

When you combine both layers, something remarkable happens: your agents accumulate intelligence over time. Every interaction is an opportunity to write something back. Every mistake can be corrected and stored. Every successful pattern can be reinforced.

That's self-evolution. Not in a science-fiction sense. In a very practical, engineering sense.

The Self-Evolving Agent Pattern

Here's the concrete pattern that unlocks self-improvement.

The agent has access to both read and write tools for the knowledge base. When it encounters something worth remembering, it writes it. When it starts a new session, it reads from the knowledge base before responding. Over time, the knowledge base grows richer and the agent's responses improve — without any human retraining.

Consider a customer-facing support agent:

Day 1: A customer asks about a product edge case. The agent searches the KB, finds nothing, researches it, and answers correctly. It then writes that edge case and the correct answer to the KB.
Day 2: A different customer asks the same question. The agent reads the KB, finds the answer immediately, responds in milliseconds. No LLM reasoning required for that step.
Week 2: A product manager updates the answer because the product changed. The agent reads the updated record. Every future session gets the new answer automatically.
Month 3: The KB now contains hundreds of edge cases, customer patterns, and domain corrections. The agent is dramatically more accurate than on Day 1 — not because of retraining, but because of accumulated knowledge.

This is the compounding effect that static agent architectures can never achieve.

Three Backends, One API

Agent Kernel ships with production-grade support for three fundamentally different knowledge storage paradigms — all behind a single, consistent interface.

ChromaDB — Semantic Memory for Text

ChromaDB is a vector database purpose-built for semantic similarity search. You write natural language text; ChromaDB embeds it and stores it as high-dimensional vectors. When an agent queries it, ChromaDB returns the most semantically relevant records — not keyword matches, but meaning matches.

This is the right backend for:

Product documentation and FAQs
Support knowledge that agents discover during operation
Domain-specific terminology and explanations
Any knowledge that requires natural language retrieval

The agent doesn't need to know the exact words used when the knowledge was stored. It asks a question in plain language and gets the most relevant answer, even if the stored text uses different phrasing.

from agentkernel.knowledgebase.chroma import ChromaManager

v_db = ChromaManager(name="ProductKB").add_schema({
    "description": "Product documentation and support knowledge. Use for product questions, feature explanations, and known issue resolutions.",
    "usage": "Pass a natural language query. Returns the most semantically relevant knowledge entries.",
    "write_format": {"text": "string (the knowledge to store)", "metadata": {"source": "string", "category": "string"}},
})

Neo4j — Relational Memory for Connected Knowledge

Neo4j is a graph database. Instead of storing isolated facts, it stores relationships between entities. This unlocks a category of agent reasoning that flat databases simply cannot support: traversal, inference, and multi-hop relationship queries.

Think about what this means for an agent:

A customer support agent can reason about which customers use which products, and which products have which known issues.
An enterprise agent can navigate org charts, escalation paths, and approval workflows.
A research agent can traverse citation graphs, author relationships, and topic hierarchies.

This is the right backend for:

Customer relationship graphs
Organizational structures and reporting lines
Concept maps and knowledge ontologies
Dependency trees (products, services, systems)
Any domain where "how is X connected to Y?" matters

from agentkernel.knowledgebase.neo4j import Neo4jManager

g_db = Neo4jManager(name="CustomerGraph").add_schema({
    "description": "Customer and product relationship graph. Use for account-level context, product usage patterns, and escalation chains.",
    "usage": "Write Cypher queries to read/write nodes and relationships.",
    "write_format": {"text": "Cypher CREATE or MERGE statement", "metadata": {"entity_type": "Customer|Product|Issue"}},
})

Starburst Galaxy — Analytical Memory for Structured Data

Starburst Galaxy is a distributed SQL query engine built on Trino. It can query across multiple data sources simultaneously — PostgreSQL, MongoDB, Google Sheets, S3, and dozens of others — using standard SQL. From the agent's perspective, it's a single, unified analytical layer over all your structured data.

This is read-only by design: Starburst is for reading structured operational data that already exists in your systems, not for agent-generated writes. It's the right backend for:

Live business metrics and dashboards
Customer transaction history
Inventory and pricing data
Any structured data that agents need to read but shouldn't write

With Starburst, your agent can answer questions like "What are the top 10 customers by revenue this quarter?" or "Which SKUs are below reorder threshold right now?" — directly from your live data systems, with no ETL pipeline in between.

from agentkernel.knowledgebase.starburst import StarburstManager

s_db = StarburstManager(name="SalesData").add_schema({
    "description": "Live sales and inventory data via Starburst Galaxy. READ-ONLY. Use for revenue queries, inventory lookups, and customer transaction history.",
    "usage": "Pass SQL SELECT statements. Use <SALES_SOURCE> as the table placeholder.",
    "query_template": "SELECT ... FROM <SALES_SOURCE> WHERE ...",
})

Semantic Map: Keeping Agents Portable

One of the most powerful details in Agent Kernel's KB design is semantic_map — and it's easy to miss if you don't look for it.

The problem it solves: physical resource names in databases change. Table names change when you migrate. Collection names differ between dev and prod. Catalog paths in Starburst differ between environments. If your agent hardcodes those physical names in its queries, you're constantly updating prompts whenever the environment changes.

semantic_map fixes this by letting agents reason over stable, logical tokens — <CUSTOMER_SOURCE>, <INVENTORY_TABLE>, <VECTOR_STORE> — while KnowledgeBuilder resolves them to the correct physical target at runtime.

semantic_map = {
    "<CUSTOMER_SOURCE>": "TABLE(kb_sheets.system.sheet(id => 'SHEET_ID_PROD'))",  # Prod
    "<INVENTORY_TABLE>": "warehouse.inventory.current_stock",
}
# In staging, swap out the values — agent prompts stay identical

Your agent stays portable. Your prompts stay unchanged. Environment-specific details live in deployment config, not in the model's context.

KnowledgeBuilder: The Composition Layer

KnowledgeBuilder is the glue that composes backends into a unified tool surface for the agent. You register one or more backends, optionally provide a semantic_map, call .build(), and get back a list of plain Python callables:

get_schemas() — returns each backend's schema so the agent can decide where to route
read_kb(backend, query, limit) — query a specific backend
write_kb(backend, text, ...) — write to a backend
get_all_kb_descriptions() — short summary of all registered backends for routing context

These callables are framework-agnostic. A framework adapter then binds them into the actual agent runtime.

from agentkernel.knowledgebase.knowledgebuilder import KnowledgeBuilder
from agentkernel.knowledgebase.chroma import ChromaManager
from agentkernel.knowledgebase.neo4j import Neo4jManager
from agentkernel.knowledgebase.starburst import StarburstManager

kb = KnowledgeBuilder(
    backends=[v_db, g_db, s_db],
    semantic_map=semantic_map,
)
kb_tools = kb.build()

Then wire into any supported framework:

# OpenAI Agents SDK
from agentkernel.openai import OpenAIToolBuilder
from agents import Agent

kb_agent = Agent(
    name="KnowledgeAgent",
    instructions="...",
    tools=OpenAIToolBuilder.bind(kb_tools),
)

The same kb_tools works identically with LangGraph, CrewAI, and Google ADK. One knowledge layer, all frameworks.

Why This Changes the Game

Here's the honest assessment of what this unlocks that wasn't possible before.

Agents that improve without retraining. Every write to the KB is a micro-improvement. Scale that across thousands of sessions and you have an agent that is genuinely smarter at month three than it was on day one — without a single fine-tuning run.

Knowledge that survives agent restarts, redeploys, and framework switches. The knowledge base is outside the agent. Swap from LangGraph to CrewAI? Your KB comes with you. Redeploy to a new environment? Your KB is still there.

Multi-agent knowledge sharing. Multiple agents — a support agent, a billing agent, a triage agent — can all read from and write to the same KB. Knowledge discovered by one agent is immediately available to all others. This is the foundation of a genuinely collaborative multi-agent system.

Specialised query capabilities per domain. Use ChromaDB for fuzzy natural language retrieval. Use Neo4j for relationship traversal. Use Starburst for SQL analytics. Route each query to the backend that's architecturally correct for the question type. No more forcing all your data through a single retrieval strategy that's wrong for most of it.

Custom backends for any storage system. Not locked in to the three built-in backends. Implement the KnowledgeBase adapter for your existing Pinecone instance, your Elasticsearch cluster, your internal knowledge API — and it plugs into the same KB tools infrastructure with zero changes to your agent code.

The Recommended Pattern: KB Router Agent

For multi-backend setups, Agent Kernel recommends dedicating one agent to knowledge routing. This agent's only job is to decide which KB to query, execute the read or write, and return results to the calling agent.

Why this matters: routing decisions benefit from inspecting schemas first. A specialised routing agent can call get_schemas(), understand what each backend contains, and make an accurate routing decision before executing. Mixing this responsibility into a task-focused agent leads to routing errors and hallucinated backends.

kb_router = Agent(
    name="KB_Router_Agent",
    instructions="""
    You manage access to multiple knowledge backends.

    Start every request by calling get_schemas() to inspect available backends.
    Then call get_all_kb_descriptions() for routing context.

    Routing rules:
    - Natural language / semantic questions → ChromaDB backend
    - Relationship or entity traversal → Neo4j backend (Cypher only)
    - Structured data / analytics / SQL → Starburst backend (READ-ONLY, no write_kb)

    When writing knowledge:
    - Use write_kb with the correct backend name
    - Never call write_kb for Starburst backends
    - Always include descriptive metadata in the write payload

    When the query contains a placeholder like <CUSTOMER_SOURCE>, keep it unchanged
    in your query string — the semantic_map will resolve it at runtime.
    """,
    tools=OpenAIToolBuilder.bind(kb_tools),
)

Technical Reference

The `KnowledgeBase` Abstract Interface

All backends — built-in and custom — implement the same contract:

Member	Type	Description
`backend_name`	`@property str`	Unique identifier used in tool calls and schemas
`connect(**kwargs)`	`abstractmethod`	Establish backend connection
`write(records, **kwargs)`	`abstractmethod`	Persist `[{"text": str, "metadata": dict}]` records
`read(query, limit, **kwargs)`	`abstractmethod`	Return top-N relevant records for query
`get_description()`	`abstractmethod`	Human-readable description for agent routing
`add_schema(config)`	Inherited	Merge config dict into backend schema
`schema()`	Inherited	Returns `{"backend": name, ...schema_config}`
`format_results(rows)`	Optional override	Format records for agent response
`close()`	Optional override	Release connections / flush buffers

Writing a Custom Adapter

from agentkernel.knowledgebase.base import KnowledgeBase, Record
from typing import Any, Iterable, List, Mapping


class PineconeBackend(KnowledgeBase):

    @property
    def backend_name(self) -> str:
        return "PineconeKB"

    def connect(self, **kwargs) -> None:
        import pinecone
        pinecone.init(api_key=kwargs["api_key"], environment=kwargs["env"])
        self._index = pinecone.Index(kwargs["index_name"])

    def write(self, records: Iterable[Record], **kwargs) -> None:
        vectors = []
        for r in records:
            embedding = embed(r["text"])  # your embedding function
            vectors.append((r["metadata"]["id"], embedding, {"text": r["text"]}))
        self._index.upsert(vectors=vectors)

    def read(self, query: str, limit: int = 3, **kwargs) -> List[Record]:
        embedding = embed(query)
        results = self._index.query(vector=embedding, top_k=limit, include_metadata=True)
        return [{"text": m["metadata"]["text"], "metadata": m["metadata"]} for m in results["matches"]]

    def get_description(self) -> str:
        return "Pinecone vector store for high-scale semantic search over product embeddings."

pinecone_kb = PineconeBackend().add_schema({
    "description": "Product embedding store — high-scale semantic similarity search.",
    "usage": "Pass a natural language query. Returns semantically nearest product entries.",
})

kb = KnowledgeBuilder([pinecone_kb, g_db], semantic_map=semantic_map)

Full Wiring Example (OpenAI Agents SDK)

from agentkernel.knowledgebase.knowledgebuilder import KnowledgeBuilder
from agentkernel.knowledgebase.chroma import ChromaManager
from agentkernel.knowledgebase.neo4j import Neo4jManager
from agentkernel.knowledgebase.starburst import StarburstManager
from agentkernel.openai import OpenAIToolBuilder
from agents import Agent, Runner

# 1. Configure backends
v_db = ChromaManager(name="DocsKB").add_schema({...})
g_db = Neo4jManager(name="RelGraph").add_schema({...})
s_db = StarburstManager(name="Analytics").add_schema({...})

# 2. Define semantic map
semantic_map = {
    "<CUSTOMER_TABLE>": "catalog.crm.customers",
    "<ORDERS_TABLE>":   "catalog.sales.orders",
}

# 3. Build KB tools
kb = KnowledgeBuilder([v_db, g_db, s_db], semantic_map=semantic_map)
kb_tools = kb.build()

# 4. Connect backends
v_db.connect(host="localhost", port=8000, collection="docs")
g_db.connect(uri="bolt://localhost:7687", user="neo4j", password="...")
s_db.connect(host="galaxy.starburst.io", port=443, token="...", catalog="kb_sheets")

# 5. Create the router agent
router = Agent(
    name="KnowledgeRouter",
    instructions="Route queries to the correct knowledge backend. "
                 "Check schemas first. Starburst is read-only.",
    tools=OpenAIToolBuilder.bind(kb_tools),
)

# 6. Run
result = await Runner.run(router, "What are our top 5 customers by revenue this month?")
print(result.final_output)

Importing from `agentkernel.knowledgebase`

from agentkernel.knowledgebase.base          import KnowledgeBase, Record
from agentkernel.knowledgebase.knowledgebuilder import KnowledgeBuilder
from agentkernel.knowledgebase.chroma        import ChromaManager
from agentkernel.knowledgebase.neo4j         import Neo4jManager
from agentkernel.knowledgebase.starburst     import StarburstManager

Knowledge bases are the layer that transforms AI agents from stateless request handlers into systems that genuinely accumulate expertise. The built-in ChromaDB, Neo4j, and Starburst backends cover the three fundamental storage paradigms. The custom adapter API means you're never locked out of your existing infrastructure.

The compounding effect is real. The first agent that writes back to the KB makes the next session better. Over time, your agents stop being expensive autocomplete and start being genuine institutional knowledge systems.

That's the shift. Build it today.

→ Knowledge Bases Documentation

→ Example: OpenAI KB Router

Originally published at kernel.yaala.ai on May 4, 2026.

Walled AI Guardrails in Practice

AK — Tue, 06 Oct 2026 10:38:02 +0000

By Yaala Labs

Walled AI gives us a clean, practical safety + PII masking pipeline for agent input/output flows. It is easy to integrate, fast to test, and useful for production guardrail baselines.

But like every real provider integration, there are edge cases.

This post covers the capabilities that made Walled AI a good fit for Agent Kernel, the real-world edge cases we encountered, and the implementation choices we made to keep behavior safe and predictable.

Why We Chose Walled AI

For Agent Kernel, we needed guardrails that could do two things quickly:

Block unsafe input before an LLM call.
Mask sensitive PII before the prompt reaches the model.

Walled AI gives both via:

Protect for safety checks.
Redact for masking sensitive values.

That made it a strong fit for a provider-level guardrail option in our framework.

What Walled AI Does Well

Before discussing edge cases, it is important to highlight the strengths that made this integration practical:

Fast safety checks that can block unsafe prompts before they hit an LLM.
Built-in PII masking flow with reversible placeholders for controlled unmasking.
Simple API surface (Protect + Redact) that is easy to operationalize.
Good fit for runtime guardrail layering in agent systems.
Optional local-model experimentation path for moderation workflows.

For many teams, this baseline is enough to ship a strong first guardrail layer quickly.

How the Flow Works in Agent Kernel

At a high level:

Each incoming text request is checked with Protect.
If safe, the same text is sent to Redact.
Masked text is forwarded to the agent.
Placeholder mapping is stored in the session’s non-volatile cache (via session.get_non_volatile_cache()).
On output, placeholders are restored from this non-volatile cache before replying to the user.

In Agent Kernel, we intentionally process requests individually and preserve non-text request objects (files/images/other) without suppressing them by default. Since Walled AI is text-focused, non-text validation should be implemented via separate hooks/policies when needed.

Local Model Support (WalledGuard-Edge)

Walled AI also supports a local moderation path through walledai/walledguard-edge (Hugging Face), which is useful for:

Offline experimentation.
Cost/performance prototyping.
Evaluating moderation behavior before wiring into hosted pipelines.

In Agent Kernel, this local path is treated as an optional complement to the default API-driven Walled AI guardrail integration.

This gives teams flexibility:

Hosted path for managed production guardrails.
Local path for controlled testing and evaluation.

Reference links:

API access and product updates: www.walled.ai
Hugging Face model page: walledai/walledguard-edge

Limitations

Walled AI is strong for baseline safety and PII redaction, but there are provider-level limitations teams should understand before production rollout.

1. No Cross-Call Placeholder Memory

Walled AI does not keep a session memory of placeholders across redaction calls, and it does not maintain thread history between requests.

Example:

Call A: "my name is john" -> my name is [Person_1]
Call B: "my brother is james" -> my brother is [Person_1]

The same label can appear again for a different value in later calls. Teams should treat placeholder IDs as call-scoped unless they add an application-side session strategy.

2. Limited PII Masking Configuration Controls

Fine-grained field-level controls can be limited for some domain requirements.

Example requirement:

Mask only CVV.
Keep account number visible (or partially visible).

If you need this type of selective policy, you may need an extra policy layer before or after provider redaction.

3. Text-Centric Guardrail Surface

The primary safety/redaction operations are text-focused. Mixed-content pipelines (text + image/file/other) still need runtime logic to preserve and route non-text objects correctly.

Issues in Existing Features

These are practical issues observed while integrating current features in Agent Kernel.

1. Short Inputs and `INPUT_SHORT`

Very short messages like "hi", "ok", or "23" can return INPUT_SHORT during redaction.

This is not a safety violation.
It means redaction was not applicable for that payload.

Agent Kernel handles this by bypassing redaction for that request and continuing.

2. Redaction Failure Handling

If redaction fails for reasons other than INPUT_SHORT, allowing the exception to bubble can fail the full request path.

In the current implementation, Agent Kernel logs the exception and re-raises it rather than returning a fallback response.

3. Tracing Context Loss on Output Rewrite

If unmasking creates a new reply object without preserving metadata, tracing tools can lose input-output linkage.

In the current implementation, unmasking returns a new AgentReplyText with rewritten text and does not preserve prompt metadata by default.

What We Improved in Agent Kernel

Based on integration feedback and code reviews, we implemented these hardening changes:

Per-request text processing for safety + redaction.
Pass-through for non-text request types.
Explicit INPUT_SHORT bypass; non-INPUT_SHORT redaction errors are logged and re-raised.
Output unmasking support, with metadata preservation still an active consideration.

Recommendations for Teams Using Walled AI

If you are integrating Walled AI into your own framework/runtime:

Treat placeholders as call-scoped unless you explicitly design session behavior.
Handle short-input redaction outcomes (INPUT_SHORT) as expected edge cases.
Do not suppress non-text content by default just because a provider focuses on text; use a separate hook/policy to validate non-text content as needed.
Keep observability context (prompt, session IDs, trace metadata) intact.
Add a policy layer if you need highly selective PII masking logic.

Final Take

Walled AI is a strong guardrail building block, especially for fast safety + PII integration.

Its biggest advantage is speed to value: you get practical safety and masking quickly, with a clean integration model.

The key is not assuming provider behavior equals application behavior.

Production-safe integrations come from the combination of provider checks, session-aware runtime logic, and explicit handling of edge cases like short inputs, placeholder collisions, and tracing continuity.

That combination is where reliability comes from.

Related Resources

Originally published at kernel.yaala.ai on March 10, 2026.

Agent Skills: Agent Kernel Builds Enterprise Agents for You

AK — Tue, 06 Oct 2026 10:35:20 +0000

By Yaala Labs

What if you never had to read a single page of Agent Kernel documentation?

What if you didn't need to know which agentic framework to use, how to wire handoffs, how to configure session persistence, or how to write Terraform for a cloud deployment?

What if you just told your coding assistant what you wanted — and Agent Kernel handled the rest?

That's exactly what Agent Skills deliver.

Agent Kernel Exposes Its Entire Capability Set as Skills

This is the idea that changes everything: Agent Kernel doesn't ask you to learn it. It teaches your coding assistant instead.

Every feature Agent Kernel supports — every framework, every deployment target, every integration, every capability — is packaged as a skill that your coding assistant can read and act on. The skills contain the same knowledge the Agent Kernel team has: the right patterns, the right config keys, the right import paths, the right framework-specific gotchas, the right Terraform modules. All of it.

When you install Agent Kernel skills, you're not installing a tutorial. You're giving your coding assistant the complete expertise to develop and deploy enterprise AI agents on your behalf. You describe what you want in plain English. Your assistant — armed with Agent Kernel's own skills — writes the code, wires the config, and gets it right.

No documentation to read. No experience required. No trial and error.

You Don't Need to Be a Developer

Traditional agent frameworks assume you're an experienced developer. You need to understand framework APIs, deployment infrastructure, config formats, dependency management. The learning curve is steep and the documentation is long.

Agent Kernel takes a radically different approach. By publishing its capabilities as skills, Agent Kernel puts its expertise directly into the hands of your coding assistant. The assistant becomes the developer. You become the director.

Want an enterprise agent that handles customer support across Slack and WhatsApp, with guardrails, session persistence, and tracing — deployed to AWS? Here's your workflow:

"Create a new agent project using OpenAI with REST API"

"Add a triage agent, a support agent, and a billing agent with handoffs"

"Add Slack and WhatsApp integration"

"Add Redis session persistence, Bedrock guardrails, and Langfuse tracing"

"Deploy to AWS Lambda with DynamoDB sessions"

"Set up automated testing with judge mode"

Six prompts. No documentation. No framework expertise. A production-grade enterprise agent — scaffolded, built, integrated, hardened, deployed, and tested.

Each prompt activates a different Agent Kernel skill. Each skill tells your coding assistant exactly what to do — not in vague terms, but with precise instructions covering every framework Agent Kernel supports: OpenAI Agents SDK, CrewAI, LangGraph, and Google ADK.

Everything Agent Kernel Can Do, Packaged as Six Skills

Agent Kernel publishes six skills that span the entire agent development lifecycle. Together, they cover every feature Agent Kernel supports:

ak-init — Scaffold a Complete Project

Your assistant creates a production-ready project structure: pyproject.toml with the right extras, agent file, tool file, config, build script, and tests. It knows the correct setup for all four frameworks and both deployment modes (containerized and serverless).

"Create a new agent project using CrewAI with REST API"

ak-build — Add Tools, Agents, and Handoffs

The skill you'll use the most. Your assistant reads your existing project — identifies the framework, lists existing agents and tools, checks the entry point — then generates code that fits seamlessly into what's already there. It knows the handoff wiring for every framework: handoffs= for OpenAI, create_supervisor() for LangGraph, sub_agents= for ADK, crew composition for CrewAI.

"Add a weather lookup tool and a support agent with handoffs to billing"

ak-add-capabilities — Guardrails, Tracing, Sessions, MCP, A2A, and More

Your assistant adds enterprise capabilities with the correct config, code, and dependencies. This single skill covers guardrails (OpenAI, Bedrock, Walled AI), tracing (Langfuse, OpenLLMetry), session persistence (Redis, DynamoDB, Cosmos DB), MCP server exposure, A2A protocol, lifecycle hooks, and multimodal support.

"Add Redis session persistence and Langfuse tracing"

ak-add-integration — Connect Messaging Platforms

Your assistant generates the handler class, environment variables, config block, and webhook setup for Slack, WhatsApp, Messenger, Instagram, Telegram, or Gmail — correctly, the first time.

"Add Slack and WhatsApp integration"

ak-cloud-deploy — Deploy to AWS or Azure

Your assistant generates complete Terraform configurations for AWS Lambda, AWS ECS/Fargate, Azure Functions, or Azure Container Apps. Includes IAM roles, networking, environment variables, and container registry setup.

"Deploy my agent to AWS Lambda"

ak-test — Test and Debug

Your assistant configures test modes (fuzzy, judge, fallback), generates test patterns, and knows how to diagnose the most common issues — from tool binding errors to session conflicts.

"Set up automated testing for my agent"

Skills Know Every Framework

Each skill isn't a generic template — it contains framework-specific knowledge for all four agentic frameworks Agent Kernel supports. When your assistant reads a skill, it learns the differences that trip up even experienced developers:

Pattern	OpenAI	LangGraph	CrewAI	Google ADK
Agent identity	`name=`	`name=` in `create_react_agent()`	`role=` (not `name=`)	`name=`
Model wrapping	Direct string	Direct string	Direct string	`LiteLlm()` wrapper
Handoff wiring	`handoffs=`	`create_supervisor()`	Module composition	`sub_agents=`

Your assistant doesn't guess which pattern to use. The skill tells it. The code is correct on the first try.

A Guided Journey, Not Isolated Commands

The six skills form a natural progression. Each skill ends with a "What to do next" section that points your assistant to the logical next step:

ak-init → ak-build ↻ → ak-add-capabilities / ak-add-integration → ak-cloud-deploy → ak-test

Your assistant doesn't just answer your current question — it knows where you are in the development journey and guides you forward. Start with scaffolding, iterate on tools and agents, layer in enterprise capabilities, connect messaging platforms, deploy to cloud, and validate with tests.

You never have to figure out "what comes next." The skills already know.

Works With Every Major Coding Assistant

Agent Skills work with GitHub Copilot, Claude Code, Cursor, Windsurf, Codex, and Aider. The ak CLI installs skills into the right directory for each assistant:

pip install agentkernel

# Install skills (defaults to GitHub Copilot)
ak skill install

# Or pick your assistant
ak skill install --assistant claude     # → .claude/commands/
ak skill install --assistant cursor     # → .cursor/rules/
ak skill install --assistant windsurf   # → .windsurf/rules/
ak skill install --assistant codex      # → .codex/rules/
ak skill install --assistant aider      # → .aider/rules/

Browse and explore:

ak skill list                  # See all 6 skills
ak skill info ak-build         # Full description of a skill
ak skill assistants            # See supported assistants

Built on an Open Standard

Agent Skills follow the SKILL.md open standard — plain Markdown files with YAML frontmatter that coding assistants automatically discover. Each skill is lean (under 5000 tokens) so your assistant reads it fully, and precise enough to produce correct code without trial and error.

Every skill also ships with an evals/evals.json — structured test scenarios that validate the assistant's output. These evals are the contract: if the assistant passes them, the generated code is correct Agent Kernel code.

Three Commands. No Docs. Enterprise Agents.

# 1. Install
pip install agentkernel

# 2. Give your assistant Agent Kernel's expertise
ak skill install

# 3. Tell it what to build
# "Create a multi-agent system with triage, support, and billing"
# "Add Slack integration and Redis sessions"
# "Deploy to AWS Lambda and set up testing"

You don't read the documentation. You don't learn the framework. You don't study the deployment patterns. Agent Kernel's skills already know all of it — and they teach your coding assistant so it can build enterprise agents for you.

Skills for Contributors Too: The `.agents` Folder

Agent Skills aren't just for users building agents. They also power Agent Kernel's own development.

The Agent Kernel repository ships a .agents/skills/ folder containing seven developer skills — the same open standard, but focused inward. These skills teach coding assistants how to contribute to Agent Kernel itself:

Skill	What It Teaches Your Assistant
ak-dev-architecture	Core abstractions, design principles, adapter pattern, execution flow — everything needed to understand the codebase
ak-dev-new-framework-integration	Step-by-step guide to add a new agent framework adapter (beyond OpenAI, CrewAI, LangGraph, Google ADK)
ak-dev-new-messaging-integration	How to add a new messaging platform (beyond Slack, WhatsApp, Messenger, Instagram, Telegram, Gmail)
ak-dev-new-guardrail-provider	How to add a new content safety provider (beyond OpenAI, Bedrock, Walled AI)
ak-dev-new-tracing-provider	How to add a new observability backend (beyond Langfuse, OpenLLMetry)
ak-dev-testing-conventions	Pytest patterns, async testing, mocking, CI/CD workflows
ak-dev-code-quality	Formatting standards, commit conventions, PR workflow

This means a new contributor doesn't need to spend hours studying the codebase before making their first contribution. They open the repo in their coding assistant, and the .agents/skills/ folder is automatically discovered. Now the assistant knows:

The architecture — how Session, Agent, Runner, Module, and Runtime fit together
The adapter pattern — that each framework lives in its own module under agentkernel/framework/
The exact steps to add a new framework, integration, guardrail, or tracing provider
The testing conventions — how to write async tests, mock external services, run CI
The code quality standards — formatting, commit messages, PR checklist

Ask your assistant "Add support for a new agent framework called X" and it reads ak-dev-new-framework-integration. It knows to create the adapter module, implement Agent, Runner, and Module subclasses, add optional dependencies, update exports, and write tests — all following Agent Kernel's established patterns.

Ask "Add a new tracing provider for Datadog" and it reads ak-dev-new-tracing-provider. It knows to implement the BaseTrace interface, create framework-specific traced runners, add config support, and wire up the factory.

The result: contributors ship features faster because their coding assistant already understands the entire codebase. The skills eliminate the onboarding curve. A first-time contributor with the right coding assistant can implement a complete framework adapter or messaging integration — correctly — in a single session.

This is the same philosophy applied in both directions. Agent Kernel exposes its capabilities as skills so users can build agents without reading docs. And it exposes its internals as skills so contributors can extend the platform without studying the codebase. Skills all the way down.

Agent Skills follow the SKILL.md open standard. Agent Kernel is open-source under the Apache 2.0 license. Get started →

Originally published at kernel.yaala.ai on March 10, 2026.

Write Once, Run Anywhere: Universal Tools for AI Agents

AK — Tue, 06 Oct 2026 10:32:57 +0000

By Yaala Labs

Stop rewriting the same tools for different AI frameworks.

Imagine building a calculator app, then discovering you need to rebuild it from scratch every time you want to run it on a different device. That's what building AI agent tools feels like today.

Write a weather lookup tool for OpenAI? It won't work with Google's framework. Build it for CrewAI? Start over if you switch to LangGraph. This wastes time and creates headaches every time you want to try a new AI framework.

Agent Kernel solves this: write your tools once, use them everywhere.

The Problem: Every Framework Wants Tools Written Differently

Think of tools as capabilities you give your AI agent—like looking up weather, searching a database, or sending emails. Right now, each AI framework requires you to write these tools in a completely different way.

Here's the same weather tool written for four different frameworks:

# OpenAI version
@function_tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# CrewAI version  
@tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# LangGraph version
@tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# Google ADK version
def _get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"
get_weather = FunctionTool(_get_weather)

It's the same weather lookup, but you have to write and maintain four different versions.

Want to switch frameworks? Rewrite everything. Want to try a new framework alongside your current one? Duplicate all your tools. Building 10 custom tools means maintaining 40 versions if you use all four frameworks.

The Solution: Write Normal Python Functions

With Agent Kernel, you write your tools as regular Python functions—no special decorators or framework-specific code:

def get_weather(city: str) -> str:
    """Returns the weather for a given city."""
    return f"Weather in {city}: sunny, 25°C"

That's it. Just a normal Python function with a helpful description. Then use it with any framework you want.

Using Your Tool with Any Framework

Once you've written your tool as a normal Python function, you can add it to agents in any framework. The only thing that changes is one line of code:

OpenAI Agents

from agents import Agent
from agentkernel.openai import OpenAIToolBuilder

weather_agent = Agent(
    name="weather",
    instructions="You provide weather information.",
    tools=OpenAIToolBuilder.bind([get_weather]),  # ← Add your tool here
)

CrewAI

from crewai import Agent
from agentkernel.crewai import CrewAIToolBuilder

weather_agent = Agent(
    role="weather",
    goal="You provide weather information",
    backstory="Use the get_weather tool for queries.",
    tools=CrewAIToolBuilder.bind([get_weather]),  # ← Add your tool here
)

LangGraph

from langgraph.prebuilt import create_react_agent
from agentkernel.langgraph import LangGraphToolBuilder

weather_agent = create_react_agent(
    name="weather",
    tools=LangGraphToolBuilder.bind([get_weather]),  # ← Add your tool here
    model=model,
    prompt="Use the get_weather tool for queries.",
)

Google ADK

from google.adk.agents import Agent
from agentkernel.adk import GoogleADKToolBuilder

weather_agent = Agent(
    name="weather",
    model="gemini-2.0-flash-exp",
    description="You provide weather information",
    tools=GoogleADKToolBuilder.bind([get_weather]),  # ← Add your tool here
)

Same get_weather function. Works everywhere.

The .bind() method translates your normal Python function into whatever format each framework needs. You don't have to worry about the details—just write your function once and use it anywhere.

Why Framework-Agnostic Tools Are So Hard

Making tools work across frameworks sounds simple, but it's actually quite challenging. Each framework has its own way of handling tools, and these differences create real technical problems.

Different Execution Models

Frameworks handle async/sync functions differently:

LangGraph (LangChain) requires you to specify whether a tool is async or sync upfront:

# Sync tools use 'func' parameter
StructuredTool.from_function(func=my_tool)

# Async tools use 'coroutine' parameter
StructuredTool.from_function(coroutine=my_async_tool)

OpenAI Agents SDK automatically handles both, but wraps them differently internally.

Google ADK expects all tools to potentially receive a tool_context parameter from the framework itself, which other frameworks don't provide.

Agent Kernel detects whether your function is async or sync and generates the right code for each framework automatically. You just write def or async def.

Different Context Mechanisms

This is the hardest problem: frameworks provide execution context (session info, runtime state) in completely different ways.

OpenAI, CrewAI, LangGraph work well with Python's standard contextvars, which lets you set context in one place and access it anywhere in the call stack:

# Set once before calling agent
context.set()

# Access anywhere in your tool
ctx = ToolContext.get()

Google ADK manages its own execution context internally and doesn't reliably propagate Python's contextvars. Instead, it passes a tool_context parameter to every tool function:

# ADK calls your tool like this:
def my_tool(city: str, tool_context: ADKToolContext):
    # ADK's context, not yours

This means your tool function signature must be different for ADK versus other frameworks. Or does it?

Agent Kernel solves this by:

Wrapping tools for ADK - Adding the tool_context parameter automatically
Bridging contexts - Converting ADK's context to Agent Kernel's unified ToolContext
Passing context through session state - Storing context IDs in ADK's session and retrieving them in the wrapper

All this happens behind the scenes. You write one function, and it works everywhere.

Different Tool Metadata Requirements

Each framework expects different information about your tool:

Framework	Name Source	Description Source	Schema Generation
OpenAI	Function name	Docstring	Automatic from type hints
CrewAI	Function name	Docstring	Automatic from type hints
LangGraph	Must specify	Must specify or falls back to function name	Must extract from function
Google ADK	Function name	Function name if no docstring	Type inspection required

Agent Kernel extracts metadata once from your Python function (name, docstring, parameters, types) and formats it appropriately for each framework.

Different Error Handling

When a tool raises an exception, frameworks handle it differently:

OpenAI catches exceptions and reports them to the model
LangGraph can retry tools or propagate errors through the graph
CrewAI logs errors and may retry depending on agent configuration
Google ADK wraps errors in its own exception types

Agent Kernel doesn't hide these differences (they're tied to framework behavior), but it ensures your tool code doesn't need to know which framework is calling it.

Different Import Paths and Dependencies

Each framework's tool classes come from different packages:

from agents import function_tool              # OpenAI
from crewai_tools import tool                 # CrewAI  
from langchain_core.tools import StructuredTool  # LangGraph
from google.adk.tools import FunctionTool     # Google ADK

If you write tools using framework-specific decorators, you're locked in. Agent Kernel's ToolBuilder classes handle these imports internally, so your tool code has zero framework dependencies.

The Hidden Complexity

Here's what Agent Kernel does behind the scenes for a single tool:

Inspects your function - signature, type hints, docstring, async/sync
Generates metadata - name, description, parameter schema
Creates framework wrapper - adds any framework-specific parameters
Handles context bridging - ensures ToolContext.get() works in your tool
Preserves semantics - maintains async/sync behavior correctly
Validates at bind time - catches errors early with clear messages

All so you can write this:

def my_tool(param: str) -> str:
    """Does something useful."""
    return result

tools = AnyFrameworkToolBuilder.bind([my_tool])

This simplicity is hard-won. Framework-agnostic tools require handling edge cases most developers never see.

Accessing Runtime Information

Sometimes your tools need to know things like "which user is asking?" or "what session is this?" Agent Kernel provides this information in a consistent way, regardless of which framework you're using:

from agentkernel.core import ToolContext

def get_weather(city: str) -> str:
    """Returns the weather for a given city."""
    # Get information about the current execution
    ctx = ToolContext.get()

    session = ctx.session      # Who's asking?
    agent = ctx.agent          # Which agent is calling this?

    # Example: Use session data for personalization
    user_prefs = session.get_non_volatile_cache().get("preferences", {})
    units = user_prefs.get("temperature_units", "celsius")

    return f"Weather in {city}: sunny, 25°C"

This works the same way across all frameworks—you don't need to learn different methods for each one.

Real Example: Switching Frameworks Is Easy

Here's a complete example using OpenAI:

from agentkernel.core import ToolContext
from agentkernel.openai import OpenAIModule, OpenAIToolBuilder
from agents import Agent

def get_weather(city: str) -> str:
    """Returns the weather for a given city."""
    if city == "Tokyo":
        return "The weather in Tokyo is sunny."
    else:
        return f"Cannot find weather for {city}."

# Create agents
weather_agent = Agent(
    name="weather",
    instructions="Use the get_weather tool for weather questions.",
    tools=OpenAIToolBuilder.bind([get_weather]),
)

math_agent = Agent(
    name="math",
    instructions="You help with math problems.",
)

triage_agent = Agent(
    name="triage",
    instructions="Route questions to the right agent.",
    handoffs=[math_agent, weather_agent],
)

OpenAIModule([triage_agent, math_agent, weather_agent])

Want to try LangGraph instead? Change just the framework-specific parts:

from agentkernel.langgraph import LangGraphModule, LangGraphToolBuilder
from langgraph.prebuilt import create_react_agent

# Same get_weather function - no changes!

weather_agent = create_react_agent(
    name="weather",
    tools=LangGraphToolBuilder.bind([get_weather]),  # Different builder
    model=ChatOpenAI(model="gpt-4o-mini"),
    prompt="Use the get_weather tool for weather questions.",
)

# Define other agents...
LangGraphModule([triage_agent, math_agent, weather_agent])

Your get_weather function? Completely untouched. No rewriting. No debugging. Just works.

Async Functions Work Too

If your tool needs to do asynchronous work (like database queries or API calls), just write it as an async function:

async def search_database(query: str, limit: int = 10) -> str:
    """Searches the database for matching records."""
    results = await db.search(query, limit=limit)
    return str(results)

# Works with any framework automatically
tools = OpenAIToolBuilder.bind([search_database])
tools = LangGraphToolBuilder.bind([search_database])
tools = GoogleADKToolBuilder.bind([search_database])

Agent Kernel handles the async details for you—just write your function normally.

Using Multiple Tools

Real agents usually need multiple tools. Just add them all to the list:

tools = OpenAIToolBuilder.bind([
    get_weather,
    search_database,
    send_email,
    get_user_profile,
])

agent = Agent(
    name="assistant",
    instructions="You're a helpful assistant with multiple tools.",
    tools=tools,
)

All tools work together seamlessly, regardless of your framework.

Why This Matters

1. Try Different Frameworks Without Rewriting Code

Want to see if LangGraph is better than OpenAI for your use case? Just switch. Your tools keep working. No migration project needed.

2. Much Simpler Testing

Test your tools as regular Python functions:

def test_get_weather():
    result = get_weather("Tokyo")
    assert "sunny" in result.lower()

No complicated framework setup. No mocking. Just normal Python testing.

3. Cleaner, More Readable Code

Your tools are just functions. Easy to read. Easy to understand. Easy to maintain. No framework magic hiding what your code does.

4. Faster Team Onboarding

New developers don't need to learn framework-specific tool systems. They write regular Python functions. Everything else is handled automatically.

Local Tools vs. MCP: When to Use Each

You might have heard of MCP (Model Context Protocol) and wonder: "Should I use MCP for my tools, or build them locally?"

The answer depends on what your tools do. Let's break it down simply:

MCP: External Services

MCP is designed for connecting to external tool servers that run as separate processes. Think of it like calling a web API or external service.

Use MCP when:

Tools are provided by external services (like a company-wide document search server)
Multiple teams share the same tool infrastructure
Tools need to run independently of your agent (different machines, different languages)
You're connecting to third-party tool providers

MCP Example:

Your Agent → Network → MCP Server → External Database

Agent Kernel Tools: Part of Your Code

Agent Kernel's tool binding is for tools that are part of your agent's business logic—functions that live in your codebase alongside your agents.

Use local tool binding when:

Tools are specific to your agent's logic (like calculating pricing, formatting data)
Tools access your application's state or databases directly
You want simple, fast function calls without network overhead
You want to test tools as regular Python code

Local Tool Example:

Your Agent → Direct Function Call → Your Code

Why Local Tools Are Often Better

For most business logic, building tools directly in your agent code is simpler and more efficient:

1. No Extra Complexity

# Local tool - just a function
def calculate_price(quantity: int, item_type: str) -> float:
    """Calculate price with discounts."""
    base_price = PRICES[item_type] * quantity
    discount = get_bulk_discount(quantity)
    return base_price * (1 - discount)

# Use it immediately
tools = OpenAIToolBuilder.bind([calculate_price])

With MCP, you'd need to:

Set up a separate MCP server process
Define network protocols
Handle connection errors and retries
Manage server lifecycle

2. Faster Execution

Local tools are just function calls—microseconds. MCP involves network requests—milliseconds or more. For tools that run frequently, this adds up.

# Local: Direct call, ~microseconds
result = calculate_price(100, "widget")

# MCP: Network round-trip, ~10-100ms
result = await mcp_client.call_tool("calculate_price", {...})

3. Easier Testing

# Test local tools like any Python function
def test_bulk_discount():
    price = calculate_price(quantity=100, item_type="widget")
    assert price < calculate_price(quantity=10, item_type="widget")

# MCP tools require running a server, mocking network calls, etc.

4. Better Debugging

When something goes wrong with a local tool, your debugger works normally. Step through your code, inspect variables, see the full stack trace.

With MCP, you're debugging across process boundaries and network calls. Much harder.

5. Simpler Deployment

Local tools deploy with your agent—one Docker container, one deployment. MCP tools need separate infrastructure, monitoring, and coordination.

When MCP Makes Sense

Don't get us wrong—MCP is valuable for the right use cases:

Shared Corporate Tools:
Your company has a central "Employee Directory" service used by 50 different AI agents. One MCP server, everyone connects to it.

External Services:

You're integrating with a third-party tool provider (like a specialized search engine or data enrichment service) that offers MCP access.

Language Boundaries:
Your tool is written in Rust for performance, but your agent is in Python. MCP lets them communicate.

Heavy Resources:
Your tool needs 64GB of RAM and a GPU. Run it on a dedicated server via MCP instead of bundling it with every agent instance.

The Practical Rule

Start with local tools. They're simpler, faster, and easier to build and test.

Only use MCP when you have a specific reason:

The tool truly needs to be external
Multiple agents need to share one tool instance
The tool is provided by someone else as a service

For most business logic—data formatting, calculations, querying your own databases, calling your internal APIs—local tools are the right choice.

Best of Both Worlds

Agent Kernel supports both approaches. Use local tools for your custom logic, and connect to MCP servers when you need external capabilities:

# Local tools for your business logic
local_tools = OpenAIToolBuilder.bind([
    calculate_price,
    format_invoice,
    check_inventory,
])

# MCP tools for external services (if needed)
# Connect to MCP server for shared document search
mcp_tools = await connect_to_mcp_server("company-docs")

# Use both together
agent = Agent(
    name="sales_assistant",
    tools=local_tools + mcp_tools,
)

The key insight: Local tools and MCP serve different purposes. Don't add MCP complexity unless you need it. For most agent development, simple local tools are the better choice.

What Your Tools Keep

When you write a tool as a normal Python function, Agent Kernel automatically extracts everything the AI needs to know:

Function name → The tool's name
Docstring → Description (helps the AI know when to use it)
Parameters → What inputs the tool needs
Default values → Optional parameters
Return type → What the tool gives back

The AI sees the same tool, no matter which framework you use.

Getting Started

Using framework-agnostic tools is simple:

1. Install Agent Kernel

pip install agentkernel

2. Write your tool as a normal function

def my_tool(param: str) -> str:
    """Description of what this tool does."""
    # Your code here
    return result

3. Add it to your agent

from agentkernel.openai import OpenAIToolBuilder
from agents import Agent

agent = Agent(
    name="my_agent",
    instructions="Use my_tool when needed.",
    tools=OpenAIToolBuilder.bind([my_tool]),
)

That's all. Three steps, and your tool works across all frameworks.

Stop maintaining multiple versions of the same tool.

Write your tools once. Test them once. Use them everywhere. That's the promise of framework-agnostic tools in Agent Kernel.

Try different frameworks. Migrate painlessly. Focus on building great tools, not maintaining duplicates.

Learn More

Tool Documentation — Complete guide with more examples
Code Examples — Working examples for all frameworks
Join our Community — Questions? We're here to help

Start building framework-agnostic tools today. Your future self will thank you.

Originally published at kernel.yaala.ai on February 18, 2026.

Agent Kernel Goes Multi-Cloud: Azure Support is Here

AK — Tue, 06 Oct 2026 10:29:48 +0000

By Yaala Labs

Your AI investment should never be hostage to a single cloud provider.

Write once. Deploy anywhere. That's not a slogan, it's now reality.

Today, we're announcing full Azure support for Agent Kernel. Your AI agents can now run on Azure Container Apps, Azure Functions, and leverage Cosmos DB for persistent memory, all with zero changes to your agent code. The same agent that runs on AWS Lambda today can run on Azure Functions tomorrow. This is multi-cloud done right.

Why Multi-Cloud Matters

The cloud landscape has fundamentally changed how enterprises think about infrastructure:

More than 90% of enterprises will operate in multi-cloud environments by 2027 (Source: Gartner)
Vendor lock-in is the top concern for cloud decision-makers
Regulatory requirements often mandate geographic or provider diversity
Cost optimization demands the flexibility to leverage competitive pricing

Yet most AI agent frameworks force you to choose. Build for AWS, rebuild for Azure. Agent Kernel eliminates this false choice.

Cloud-Agnostic by Design

Agent Kernel wasn't retrofitted for multi-cloud, it was architected for it from day one.

The separation is clean:

Your agent logic stays unchanged across clouds
Agent Kernel runtime handles the abstraction
Cloud-specific adapters manage infrastructure differences

What's Available on Azure

Serverless: Azure Functions

Perfect for variable workloads and cost-sensitive deployments:

Automatic scaling from zero to thousands of concurrent executions
Pay only for what you use
Native integration with Azure API Management

Containerized: Azure Container Apps

Ideal for consistent, low-latency workloads:

Managed Kubernetes without the Kubernetes complexity
Built-in scaling and load balancing
Reduced cold start latency compared to serverless

Memory: Cosmos DB Integration

Enterprise-grade session persistence:

Global distribution with multi-region writes
Guaranteed single-digit millisecond latency
Automatic and instant scalability

Full Enterprise Feature Parity

Azure deployments get the complete Agent Kernel feature set:

Observability: Full tracing, metrics, and audit logs across all agent operations
Guardrails: Content safety and PII protection with OpenAI Guardrails support
Comprehensive Test Framework: CLI-based testing and automated scenario validation
MCP & A2A Support: Multi-context processing and agent-to-agent communication

No compromises. No feature gaps. The same production-grade capabilities on every cloud.

Getting Started

Deploying to Azure is as simple as deploying to AWS:

# Clone an Azure example
git clone https://github.com/yaalalabs/agent-kernel
cd examples/azure-containerized/openai-cosmos/deploy

# Configure and deploy
terraform init
terraform apply

Your agents. Your framework. Your choice of cloud.

The Road Ahead: Google Cloud Platform

Multi-cloud isn't complete with two providers. GCP support is our next milestone.

We're bringing Agent Kernel to Google Cloud with:

Cloud Run for containerized workloads
Cloud Functions for serverless execution
Firestore and Cloud Spanner for persistent memory

The goal remains unchanged: write your agent once, deploy it everywhere.

Join the Multi-Cloud Movement

Agent Kernel is open source and community-driven. Whether you're running on AWS today and evaluating Azure, or building greenfield with multi-cloud requirements, we've got you covered.

The future of AI agents is multi-cloud. The future is now.

Originally published at kernel.yaala.ai on February 16, 2026.

Safe AI at Scale: Introducing Guardrails for Agent Kernel

AK — Tue, 06 Oct 2026 10:26:06 +0000

By Yaala Labs

Deploying AI agents in production comes with critical business risks: brand damage from inappropriate responses, regulatory penalties from data leaks, and customer trust erosion from security breaches. Today, we're announcing Guardrails for Agent Kernel - enterprise-grade content safety that protects your business while accelerating your AI initiatives.

The Business Case for AI Guardrails

Your AI agents are powerful. But are they safe for your business?

Every unguarded AI interaction is a potential liability:

💰 Financial Risk

Data breach penalties: GDPR fines up to €20M or 4% of global revenue
HIPAA violations: Up to $1.5M per year for healthcare data exposure
PCI DSS non-compliance: Fines, increased processing fees, and contract termination
Legal costs: Class-action lawsuits from PII leakage

🎯 Brand & Reputation Risk

Inappropriate content: One viral screenshot of your AI saying something offensive can tank customer trust
Off-brand responses: Inconsistent messaging damages brand equity
Customer service failures: Frustrated users share negative experiences publicly
Competitive disadvantage: Customers choose competitors with safer AI

⚖️ Compliance & Regulatory Risk

Industry regulations: Healthcare (HIPAA), finance (PCI DSS), insurance (state regulations)
Privacy laws: GDPR, CCPA, PIPEDA, and emerging global privacy frameworks
Sector-specific: Legal advice restrictions, financial guidance disclaimers
Audit failures: Non-compliant AI systems block certifications and partnerships

The Solution: Guardrails That Work for Business

Agent Kernel's guardrails deliver measurable business value:

✅ Reduce legal exposure - Automatic PII detection prevents data leaks before they happen

✅ Accelerate compliance - Pre-built policies for HIPAA, PCI DSS, and GDPR requirements

✅ Protect brand reputation - Block harmful content before customers see it

✅ Enable faster deployment - Pre-configured safety layers reduce time-to-market

✅ Lower operational costs - Automated content filtering reduces manual review overhead

Two Enterprise-Grade Options

Choose the right guardrail provider for your business needs:

🛡️ OpenAI Guardrails - Fast Time-to-Value

Perfect for startups and mid-market companies needing rapid deployment:

Quick setup with API key authentication
Flexible policies you can adjust without vendor dependencies
Works across any cloud or on-premise infrastructure
Cost-effective for variable workloads

Best for: SaaS companies, cross-cloud deployments, rapid MVP launches

🔒 AWS Bedrock Guardrails - Enterprise Control

Ideal for large enterprises with AWS infrastructure:

30+ PII types including medical records and financial data
Native AWS integration with IAM, CloudWatch, and audit trails
Granular control through AWS Console
Enterprise SLAs and support

Best for: Healthcare, financial services, regulated industries, AWS-native stacks

Real Business Impact

💼 Customer Support: Protect Your Customers

Challenge: Support chatbot could leak customer phone numbers or credit card details

Solution: Output guardrails detect and block PII before reaching users

Result: Zero data breach incidents, maintained customer trust, avoided GDPR fines

🏥 Healthcare: HIPAA Compliance Made Simple

Challenge: Patient assistant must never leak protected health information

Solution: AWS Bedrock guardrails with comprehensive PHI detection

Result: Passed HIPAA audit, enabled telemedicine expansion, protected patient privacy

🏦 Financial Services: Regulatory Peace of Mind

Challenge: Banking assistant can't provide unauthorized financial advice

Solution: Topic filters block investment and legal guidance

Result: Met compliance requirements, accelerated product launch, avoided regulatory scrutiny

For Developers: Technical Deep Dive

👨‍💻 The following sections are for technical teams implementing guardrails.

If you're a developer, architect, or DevOps engineer, read on for implementation details, code examples, and integration patterns. Business stakeholders have all the information they need above to understand the value proposition.

Why Guardrails Matter (Technical Perspective)

AI agents are incredibly powerful, but without proper safeguards, they can:

Generate harmful or inappropriate content that damages your brand
Leak sensitive information (PII) like credit cards, SSNs, or health records
Fall victim to jailbreak attempts that bypass safety instructions
Produce off-topic responses that confuse or frustrate users
Violate compliance requirements in regulated industries

Guardrails act as protective layers around your agents, validating content before it reaches your agent (input guardrails) and before responses reach your users (output guardrails). Think of them as security checkpoints that ensure every interaction meets your safety and policy requirements.

Technical Implementation: Two Powerful Options

Agent Kernel supports two industry-leading guardrail providers, each with unique technical strengths:

🛡️ OpenAI Guardrails

OpenAI's guardrails provide sophisticated content moderation with customizable policies:

Content Filtering: Block violent, sexual, hateful, or self-harm content
Prompt Injection Detection: Identify jailbreak attempts and prompt manipulation
PII Detection: Catch sensitive data like emails, phone numbers, SSNs
Custom Keywords: Create domain-specific blocklists
Flexible Scoring: Fine-tune sensitivity thresholds per policy

Perfect for:

Customer-facing chatbots requiring brand safety
Applications handling user-generated content
Teams already using OpenAI infrastructure
Rapid prototyping with quick policy setup

Quick Setup:

pip install agentkernel[openai]

guardrail:
  input:
    enabled: true
    type: openai
    model: gpt-4o-mini
    config_path: guardrails_input.json
  output:
    enabled: true
    type: openai
    config_path: guardrails_output.json

🔒 AWS Bedrock Guardrails

Amazon Bedrock provides enterprise-grade content filtering integrated with AWS services:

Content Filters: Violence, sexual content, hate speech, insults, and more
30+ PII Types: Comprehensive detection including passports, medical records, financial data
Topic Filters: Block entire conversation topics (investments, legal advice, etc.)
Word Filters: Profanity and custom word blocking
Contextual Grounding: Ensure responses stay grounded in provided context (coming soon)
AWS Integration: Native IAM roles, CloudWatch logging, compliance controls

Perfect for:

Enterprise deployments requiring AWS compliance
Applications processing sensitive data
Teams leveraging AWS infrastructure
Scenarios needing detailed PII detection (healthcare, finance, legal)

Quick Setup:

pip install agentkernel[aws]

guardrail:
  input:
    enabled: true
    type: bedrock
    id: your-guardrail-id
    version: "1"
  output:
    enabled: true
    type: bedrock
    id: your-guardrail-id
    version: "1"

How It Works: Input and Output Protection

Guardrails integrate seamlessly into Agent Kernel's execution pipeline through our hooks system:

Input Guardrails: Validate Before Processing

Input guardrails intercept user requests before they reach your agent:

from agentkernel.guardrail import InputGuardrailFactory
from agentkernel.core import PreHook

class SafetyCheckHook(PreHook):
    def __init__(self):
        self.guardrail = InputGuardrailFactory.get(
            provider="openai",
            config_path="guardrails_config.yaml"
        )

    async def on_run(self, session, agent, requests):
        # Validate input - blocks harmful content automatically
        return await self.guardrail.on_run(session, agent, requests)

If a violation is detected, the guardrail blocks the request and returns a safe error message - your agent never sees the harmful input.

Output Guardrails: Validate Before Delivery

Output guardrails validate agent responses after generation but before reaching users:

from agentkernel.guardrail import OutputGuardrailFactory
from agentkernel.core import PostHook

class OutputSafetyHook(PostHook):
    def __init__(self):
        self.guardrail = OutputGuardrailFactory.get(
            provider="bedrock",
            guardrail_id="abc123xyz",
            guardrail_version="1"
        )

    async def on_run(self, session, agent, requests, reply):
        # Validate output - blocks unsafe responses
        return await self.guardrail.on_run(session, agent, requests, reply)

If the response contains PII, inappropriate content, or violates policies, the guardrail intercepts it and returns a filtered or replacement message.

The Power of Pluggable Architecture

Here's where Agent Kernel truly shines: our clean, pluggable architecture makes guardrails extensible.

Both OpenAI and AWS Bedrock guardrails are implemented using the same base interface. This means:

🎯 Easy Provider Switching

Switch providers with a single configuration change - no code changes needed:

# Switch from OpenAI to Bedrock
guardrail:
  input:
    enabled: true
    type: bedrock  # was: openai
    id: your-guardrail-id
    version: "1"
  output:
    enabled: true
    type: bedrock
    id: your-guardrail-id
    version: "1"

🔌 Community Contributions Welcome

Want to add support for a new guardrail provider? Our architecture makes it straightforward:

Create a new provider module (e.g., custom_guardrail.py)
Extend InputGuardrail class for input validation and OutputGuardrail class for output validation
Implement your provider-specific validation logic in the on_run() method
Register your provider in InputGuardrailFactory and OutputGuardrailFactory

Example structure:

from agentkernel.guardrail import InputGuardrail, OutputGuardrail
from agentkernel.core.base import Agent, Session
from agentkernel.core.model import AgentReply, AgentRequest

class MyProviderInputGuardrail(InputGuardrail):
    async def on_run(self, session: Session, agent: Agent, 
                     requests: list[AgentRequest]) -> list[AgentRequest] | AgentReply:
        # Your validation logic here
        return requests  # or return AgentReply to block

class MyProviderOutputGuardrail(OutputGuardrail):
    async def on_run(self, session: Session, requests: list[AgentRequest],
                     agent: Agent, agent_reply: AgentReply) -> AgentReply:
        # Your validation logic here
        return agent_reply

The community can add new guardrail options easily - whether it's commercial providers, open-source tools, or custom in-house solutions. The clean separation between guardrail logic and Agent Kernel's execution framework means contributions are simple and maintainable.

📦 Framework-Agnostic

Because guardrails are implemented as hooks, they work across all supported frameworks:

OpenAI Agents SDK ✅
LangGraph ✅
CrewAI ✅
Google ADK ✅

Write your guardrail configuration once, use it everywhere.

Choosing the Right Provider

Both providers offer robust content safety, but they excel in different scenarios:

Feature	OpenAI Guardrails	AWS Bedrock
Prompt Injection Detection	✅ Advanced	⚠️ Basic
PII Types	12+ common types	30+ comprehensive
Custom Policies	✅ Flexible YAML	✅ AWS Console
Deployment	Any cloud/on-prem	AWS only
Setup Complexity	Simple API key	AWS IAM + Guardrail ID
Cost Model	Per API call	Per text unit
Best For	Rapid prototyping, cross-cloud	Enterprise AWS, healthcare/finance

Pro Tip: Many teams start with OpenAI Guardrails for development and switch to Bedrock for production AWS deployments. Agent Kernel's pluggable design makes this migration seamless.

Coming Soon: Exciting Additions

We're not stopping here. The guardrails roadmap includes:

🧱 Walled.ai Integration

Walled.ai provides specialized prompt injection and jailbreak detection. We're working on native support to give you even more options for protecting against adversarial inputs.

🎭 PII Masking Feature

Beyond detection, we're building automatic PII masking that will:

Detect sensitive data in real-time
Replace PII with synthetic equivalents or redaction markers
Preserve context while removing identifiable information
Support custom masking rules per data type

This will be especially valuable for:

Call center agents processing customer data
Healthcare applications handling PHI
Financial services managing payment information
Any application needing GDPR/CCPA compliance

Stay tuned for announcements as these features roll out!

Real-World Use Cases

Customer Support Bot

# Protect customer conversations
guardrail:
  input:
    enabled: true
    type: openai
    model: gpt-4o-mini
    config_path: guardrails_input.json
  output:
    enabled: true
    type: bedrock
    id: pii-filter-guardrail
    version: "1"

Result: Block abusive customer inputs, prevent agent from leaking PII in responses

Healthcare Assistant

# HIPAA-compliant patient interactions
guardrail:
  input:
    enabled: true
    type: bedrock
    id: hipaa-input-guardrail
    version: "2"
  output:
    enabled: true
    type: bedrock
    id: hipaa-output-guardrail
    version: "2"

Result: Comprehensive PHI detection, compliance audit trails, AWS security controls

Enterprise Knowledge Base

# Prevent data leakage in company chatbot
guardrail:
  output:
    enabled: true
    type: openai
    config_path: guardrails_output.json

Result: Block accidental disclosure of proprietary information, filter sensitive company data

Get Started with Guardrails Today

1. Choose Your Provider

OpenAI Guardrails:

pip install agentkernel[openai-guardrails]
export OPENAI_API_KEY=your-key

AWS Bedrock:

pip install agentkernel[bedrock]
aws configure  # Set up AWS credentials

2. Configure Your Policies

Create config.yaml with your guardrail settings:

guardrail:
  input:
    enabled: true
    type: openai  # or bedrock
    model: gpt-4o-mini  # for OpenAI
    config_path: guardrails_input.json
    # For Bedrock, use: id: your-id and version: "1" instead
  output:
    enabled: true
    type: openai
    config_path: guardrails_output.json

3. Deploy with Confidence

Your agents now have enterprise-grade content safety:

Automatic input validation
Output filtering and PII detection
Compliance-ready audit trails
Framework-agnostic protection

Documentation and Examples

We've created comprehensive guides to get you started:

Guardrails Overview - Architecture and concepts
OpenAI Guardrails Guide - Complete setup and configuration
AWS Bedrock Guide - IAM setup, policies, and best practices
Working Examples - Copy-paste ready code

Join the Community

Guardrails are just the beginning. With Agent Kernel's pluggable architecture, we're building an ecosystem where the community can contribute new providers, safety mechanisms, and integrations.

Want to contribute?

Add support for new guardrail providers
Share your custom safety hooks
Improve documentation and examples
Request features and vote on priorities

Connect with us:

GitHub: yaalalabs/agent-kernel
Discord: Join our community
Issues: Report bugs or suggest features
Discussions: Ask questions and share ideas

The Future is Safe AI

As AI agents become more powerful and widespread, content safety isn't optional - it's essential. Agent Kernel's guardrails give you:

✅ Multi-provider flexibility - Choose the best tool for each use case

✅ Pluggable architecture - Easy to extend and contribute

✅ Framework-agnostic - Works with any agent framework

✅ Production-ready - Enterprise-grade safety and compliance

✅ Community-driven - Built for extensibility and collaboration

Deploy your agents with confidence, knowing they're protected by best-in-class content safety guardrails.

Ready to build safer AI? Get started with guardrails today →

Built with ❤️ by Yaala Labs

Have questions about guardrails? Join our Discord community or open an issue on GitHub.

Originally published at kernel.yaala.ai on January 13, 2026.

DEV Community: AK

Scheduled Tasks in Agent Kernel: Work That Runs Without Anyone Asking

An Agent That Works While You Sleep

Just Ask. In Plain English.

What Teams Are Using It For

Nothing Gets a Second-Class Path

From Your Laptop to Production

The Bottom Line

Your Cluster, Your Data, One Helm Chart: Agent Kernel on On-Prem Kubernetes

Why This Matters

The Same Pipeline, Now in Pods

Your Images, the Chart's Wiring

Three Flavors, Zero Forked Templates

Pick Your Broker

WebSockets That Survive a Rollout

Scaling on the Signal That Matters

A Sandbox Worker Tier, Inside the Same Chart

Built for Air Gaps

Observability Without Surprises

Get Started

Scaling Agent Kernel on AWS: Decoupling Request Handling from Agent Execution

Why This Matters, Before the How

Where the Simple Setup Runs Out of Road

Putting a Queue in the Middle

Two Deployment Shapes, One Pipeline

Lambda: Scaling You Don't Have to Configure

ECS: Long-Running Services, Explicit Scaling

The Same Guarantee, Delivered Four Ways

Config In, Not Code Change

What's Next

Get Started

Introducing the Agent Kernel Execution Broker: A Safe Place for AI Agents to Run Code

One Broker Between Agents and Every Sandbox

Your Containers, Your Rules

Connect to Systems You Already Own

Five Providers Out of the Box

Sessions and a Lifecycle You Never Manage

Framework-Neutral, Plug and Play

The Bottom Line

Agent Kernel Now Runs on GCP - AWS, Azure, GCP, On-Prem. One Platform.

What's Included

The Runtime That Takes Agents to Production

The Full Picture

Get Started

Agent Kernel Is Live at Climate Impact X

From Complexity to Production in Weeks

What Agent Kernel Enabled

Knowledge Bases: The Missing Layer That Lets AI Agents Self-Evolve

What's Actually Wrong with Today's AI Agents

Durable Knowledge: The Layer Below Sessions

The Self-Evolving Agent Pattern

Three Backends, One API

ChromaDB — Semantic Memory for Text

Neo4j — Relational Memory for Connected Knowledge

Starburst Galaxy — Analytical Memory for Structured Data

Semantic Map: Keeping Agents Portable

KnowledgeBuilder: The Composition Layer

Why This Changes the Game

The Recommended Pattern: KB Router Agent

Technical Reference

The KnowledgeBase Abstract Interface

Writing a Custom Adapter

Full Wiring Example (OpenAI Agents SDK)

Importing from agentkernel.knowledgebase

Walled AI Guardrails in Practice

Why We Chose Walled AI

What Walled AI Does Well

How the Flow Works in Agent Kernel

Local Model Support (WalledGuard-Edge)

Limitations

1. No Cross-Call Placeholder Memory

2. Limited PII Masking Configuration Controls

3. Text-Centric Guardrail Surface

Issues in Existing Features

1. Short Inputs and INPUT_SHORT

2. Redaction Failure Handling

3. Tracing Context Loss on Output Rewrite

What We Improved in Agent Kernel

Recommendations for Teams Using Walled AI

Final Take

The `KnowledgeBase` Abstract Interface

Importing from `agentkernel.knowledgebase`

1. Short Inputs and `INPUT_SHORT`

Skills for Contributors Too: The `.agents` Folder