Kpow CLI, terminal UI, and agentic skills

Hi everyone, Chad Harris here from Factor House. I'm really excited to give you a sneak preview of what we've been working on. It's a CLI and a set of agentic tools to help you access and keep your Kafka cluster accessible to you, your teams, and your agentic workflows.

We'll start with a demonstration of the CLI. The CLI uses the Kpow API to let you access almost anything you can do from the Kpow web application. The only thing we don't support at the moment is data consumption and data production - those will be coming soon as well.

Let's take a look. I can run a command here and inspect my brokers - that's pretty cool. I can say get topic assignments. This one's interesting because I can use the --output json flag, and that's what your agents will use - it makes it easier for them to consume. But for us humans, it comes back as a nice table. Pretty much everything you'd expect from a CLI for Kpow is available.

The added bonus we're very excited about - and we think platform engineers are going to love this - is the terminal UI. Here we go. It looks a bit like the web app, except it's all rendered in the terminal, and it's responsive, which is pretty cool. We can see the brokers, and navigate through the disk, config, KRaft, and ACL views for the brokers. All of these are hotkeys - I can hit the number 3 to check out our topics, then navigate through the subtabs using N and P. I can select a topic and hit I to drop into the Data Inspect tab, with all the features of Data Inspect running from the terminal. Let's run a quick data inspection query: value.destination equals... - there we go, and we've got all the luggage that's made it to Melbourne in the last few minutes.

We've also got Signals available - the new Signals feature is now available in both the API and the CLI, so we can inspect everything we need to check. If you're using Flink, we have some Flink support available as part of our platform product too - you can access the state of your Flink jobs, and all of the tasks and nodes within them.

A little sneak peek of something we're still working through: we've got some more advanced MirrorMaker 2 replication metrics. We've also got a bit of Connect here, so we can see a few failing connectors - that's going to be interesting in a few minutes. The last thing is the consumer groups view. We can inspect groups, reset offsets, and do whatever else we need to.

That's the terminal UI - and what's most exciting is the agentic skills we've built around all of this. I'm going to jump into my Claude session and start asking Claude a bunch of questions.

We saw a couple of failed connectors in the TUI, so first I'll ask: "Are my connectors healthy?" Claude is doing its thing - it's loaded the Kpow Connect Status skill, and it'll take around 30 seconds to a minute to complete this workflow. Essentially, it's using that skill to understand how to query the CLI, which gives it all the context it needs. That's what's really important about agentic workflows: an agent is only as good as the context you give it. We've worked hard to make sure the agents get all the correct context they need to answer questions like this.

Great - it's come back with a really good overview of what's happening with our connectors. It's pointed out that three of them aren't running: two are new connectors I just deployed to connect to a Databricks Unity Catalog. They're not moving data and are exiting due to an unrecoverable exception. Claude pulled the exception and interpreted it for us: Unity Catalog doesn't yet support this particular endpoint (most other catalogs do), and our connector is configured to use it to create the Iceberg table. It correctly identifies this as a catalog issue, not a connector issue - restarting the connector will just fail until that's fixed. We've also got a Debezium Postgres connector that isn't moving data. It couldn't obtain a connection - connection refused. Claude tells us the Postgres instance is refusing TCP connections, which is true in this case: the database is down or unreachable. Again, restarting won't help.

Next I'll ask: "Why did the Iceberg syncs fail?" This gives a bit more detail on why the syncs are failing - the Unity Catalog limitation - and how we could fix it: create the tables by hand in Unity Catalog and turn off auto-create, and the connectors will start. It's given us everything we need to solve this problem.

Last question - one I used to get asked a lot: "Why isn't my service getting data?" Half the time the answer is that the service is getting data, but something else is wrong with it - though of course that's not always the case. Let's ask why the airline analytics service isn't getting any data. We've got our answer, and it turns out we are getting data - with proof: messages are being produced to that topic, along with the total message count and our consumer group. The group is stable, we're only two messages behind, and we can see the consumption rate and last commit time. So we know the service is consuming data - the issue must be inside the service itself. There's also an extra piece of information: Claude noticed the instance has been restarting a few times recently, which may point to some temporary latency during consumer group rebalances. Overall, though, the topic is healthy and the service is consuming data - and it gives us the actual CLI command we can run ourselves to check this in future.

One final note on the CLI: it runs with your existing single sign-on (OIDC) setup, your existing RBAC rules, and your existing tenancy configuration, if you have one set up. So your CLI users, terminal UI users, and agentic users all get the same control and governance in place - you don't need to do anything additional to your existing OIDC workflows. We chose OIDC specifically here because that's what the MCP specification mandates - if you want to use MCP, you have to use OIDC or OAuth 2. So we're piggybacking on that for our MCP and API v2 support as well.

We just run kpow configure. I've entered the base URL, and then I can choose either OpenID Connect, which goes through the regular browser sign-in flow, or an unauthenticated deployment for Community Edition. These questions are normally pre-populated based on your configuration. It didn't open the browser this time because I already have a refresh token - quite cool, it just used that to extend my access. If I didn't have the refresh token, it would have opened the browser and taken me through the usual single sign-on flow.

Thanks for watching, everybody - we're really excited to release this. The CLI, terminal UI, and agent skills will be coming out next week, closely followed by version 2 of the API, which will include MCP.