Pub/sub for AI agents, when nobody knows the topics yet
You do not know the taxonomy yet, so you are filtering in every consumer. A topic broker asks you to name the content before you have it, and agent systems produce text whose categories nobody has settled. Semantik routes on the content itself, so a subscriber declares what it cares about and starts receiving matches without anyone adding a topic.
An agent event bus in two calls
These calls need an API key. Create one under Developer keys and export it as NOETIVE_KEY_SECRET. Publishing, searching and subscribing are metered, so your account needs a payment method attached before they answer.
curl -sS https://semantik.noetive.io/v1/publish -H "Authorization: Bearer $NOETIVE_KEY_SECRET" -H "Content-Type: application/json" -d '{"namespace":"global","model":"Qwen3-Embedding-4B","dimensions":1024,"items":[{"text":"Renamed validateCart to validateCartAsync in cart/validate.go. It now returns (Cart, error) instead of bool."}]}'This uses the shared global namespace, which other Noetive customers can read. Point it at a namespace of your own before you send anything real.
curl -sS -N https://semantik.noetive.io/v1/subscribe -H "Authorization: Bearer $NOETIVE_KEY_SECRET" -H "Content-Type: application/json" -d '{"namespace":"global","model":"Qwen3-Embedding-4B","dimensions":1024,"query":"MATCH DIRECTION([\"changed a shared file\", \"changed a function signature other code calls\"]) CONE 0.4 AND NOT DISTANCE(\"finished the task, nothing to report\") WITHIN 0.5"}'This uses the shared global namespace, which other Noetive customers can read. Point it at a namespace of your own before you send anything real.
A topic name is a bet you place before the data arrives
Kafka, NATS and Redis all work the same way at the routing layer. A publisher picks a name. A subscriber picks a name or a pattern. Delivery happens when the two match. That design is correct, and it is why those systems are fast: matching a string is cheap, and every one of them has spent a decade getting very good at moving bytes once the match is made.
It assumes you knew the right name in advance. In an agent system that assumption breaks on the first interesting day. An agent produces a finding that belongs to a category nobody defined. A new consumer wants a slice that cuts across four existing topics. Someone adds alerts.payments.high and now half the useful messages are on alerts.payments because they were published before the split. The taxonomy is always one week behind the content.
Semantik is a semantic message broker, which means the subscriber's predicate replaces the publisher's label. The subscriber says what region of meaning it wants, in SemQL, and every message that lands in that region is delivered. Publishers do not change. Nothing gets renamed.
| Kafka | NATS | Redis | Semantik | |
|---|---|---|---|---|
| How a subscriber says what it wants | Topic and partition name | Subject with wildcards | Channel name or glob | A SemQL predicate over meaning |
| Who fixes the taxonomy | The publisher, up front | The publisher, up front | The publisher, up front | The subscriber, at any time |
| An interest no topic covers | Add a topic, change publishers | Add a subject, change publishers | Add a channel, change publishers | Write a query, publishers unchanged |
| Ordering | Total order per partition | No global ordering | None | None |
| Delivery | At-least-once, with offsets and consumer groups | At-most-once in core, at-least-once with JetStream | At-most-once, nothing stored | At-least-once, dedupe on message_id |
| Reading the past | Replay by offset | Replay with JetStream | Not available | Search by meaning, not offset replay |
| Splitting one stream across workers | Consumer groups | Queue groups | Not built in | Not built in, one subscription per consumer |
| Raw throughput | Highest | Very high | Very high | Not the design goal, every message is matched against every live query |
| You operate | A cluster | A cluster | A server | Nothing |
Reach for Kafka or NATS when
- You know the taxonomy up front and it is stable. Topic names are the cheapest routing there is when the names are right.
- You need ordering. Kafka gives total order per partition. Semantik gives none, and does not pretend to.
- You need the lowest cost per message at very high volume. That is what those systems are built for, and they are extremely good at it.
- You need a worker pool to split one stream. Consumer groups and queue groups solve that. Semantik has no consumer-group concept, so every matching consumer sees every match.
- You need to replay from an exact position. Offsets do that.
Reach for Semantik when
- You do not know the content taxonomy in advance, and it keeps moving. This is the case Semantik exists for.
- A new subscriber has to start receiving relevant messages without anyone adding a topic or redeploying a publisher.
- Your subscribers each want a different slice of the same stream, and the slices overlap. One publish matches every subscription it belongs in, with no fan-out wiring.
- "Like this, but not like that" is the natural way to say what you want. That is a CONTRAST clause, and it has no equivalent in a topic name.
- The same content needs a live stream and a backward-looking search, in one query language.
What this does not claim
Semantik does not replace Kafka. If raw throughput and ordering are your constraints, a topic broker wins and it is not close. Plenty of systems will want both: a topic broker moving the volume, Semantik carrying the messages whose category nobody agreed on.
It is not an interop standard. It is a service you call over HTTP.
It does not replace agent-to-agent delegation. Semantik tells an agent that something happened. Assigning work, tracking a task and closing it out belong somewhere else.