Show HN за 28 мая 2026 г.

Hi HN, we’re open-sourcing ktx. It’s an executable context layer that makes agents reliable on your data stack.

We built it after going through the experience of building production-grade data agents for dozens of companies. If you’ve also tried building them, or simply tried using Claude Code or Codex on your data warehouse, you’ll know that accuracy is the #1 issue. Agents are great at generating valid SQL, but it’s not always correct SQL.

To cite a few examples of “agents gone wrong”: - Stale column + hidden business rule: when preparing a board report, a finance analyst asks Claude Code for “ARR by customer segment”, it derives ARR from multiple tables (subscriptions, plans, accounts), then groups by accounts.industry. But CC doesn’t know that this industry column was deprecated a few months prior, or that past board reports excluded paused subscriptions from the ARR calculation - Join fanout: a data analyst at a retailer uses their company’s internal agent to prep a product revenue deck for a QBR. The agent joins orders to order_items, then sums orders.total_amount_cents grouped by order_items.product_id. The SQL runs fine, but each order’s revenue is repeated once per line item, which most people will miss if most orders only have 1 item - Missing attribution logic: a marketing analyst asks Codex “Which campaigns drove the most revenue?” Codex joins marketing_touches to users to orders and groups by utm_campaign. But since each order can have multiple touches before purchase, the same order can be credited to first touch, last touch, every touch, or every campaign the user clicked before buying. If the agent chooses the method that doesn’t match the team’s attribution logic, they’ll make suboptimal decisions

To solve this at first we gave the agent more context through skills + a wiki-style knowledge base. That gives it some useful extra context but still relies on it writing the SQL without incorrect assumptions.

The next solution we explored was implementing a classic semantic layer. That solves the executable part, but they’re such a pain to build and maintain since they were made for legacy BI tools. Plus as a standalone tool, they lack all the useful context from unstructured data sources like internal docs.

So we built ktx and split it into 2 parts: 1. Business context goes in Markdown wiki pages that are auto-ingested and auto-populated 2. Queryable definitions go into YAML files that define tables, row grain, joins, measures, dimensions, filters, and filter groups

That way, when an agent needs a metric, it asks ktx for a measure, dimensions, filters, and filter groups instead of writing the whole query itself. ktx’s planner chooses the join path, uses grain and relationship metadata, catches issues like join fanout and chasm joins, and compiles the warehouse SQL, while utilizing the extra unstructured knowledge it has access to.

ktx is Apache 2.0. It can ingest from most warehouses (BigQuery, Snowflake, Postgres & others), modeling tools (dbt, MetricFlow, LookML), BI tools (Looker, Metabase), doc tools like Notion, and corrections from user interactions.

Install manually: npm install -g @kaelio/ktx ktx setup

Or give this prompt to your agent: Run npx skills add Kaelio/ktx --skill ktx and use ktx skill to install and configure ktx

We’d especially like feedback from people who’ve tried using Claude Code, Codex, or building custom agents on analytics warehouses. Where did they fail? And what did you try to make the answers more reliable?

Built an open JSON Schema for defining AI agent teams.

Multi-agent systems are becoming a real deployment pattern — not single assistants, but teams with roles, handoffs, and human checkpoints. But there's no shared way to define one that travels across frameworks. Every implementation is scattered, locked to whichever tool you picked first. Built the schema to fix that.

The schema lives at schema.openenvelope.org and is registered in SchemaStore, so if you drop a .envelope.json file in VS Code you get autocomplete and validation without installing anything. It's also on npm as @openenvelope/schema if you want to validate programmatically.

The spec covers: agent definitions (role, prompt, model, access policy), supervisor/sub-agent hierarchy, human-in-the-loop gates, pipelines, schedules, and secrets/variables that get injected at deploy time. Access policies let you declare exactly which hosts each agent can call — the runtime enforces this at the network level, not in the prompt.

The goal is a portable definition format — define a team once, any compatible runtime can execute it. Similar to how Dockerfiles describe a container without being tied to a specific host. There's a managed runtime at openenvelope.org but the schema is Apache 2.0 and anyone can implement it.

Happy to answer questions on any part of the spec — especially interested in feedback from people who've built multi-agent systems and have opinions on what's missing.

For years I've used paper and a printed clock to organise my day. Found it way better than any list or timeline app.

Played around a bit and made a digital clone to speed things up: Reassign.app (best experience is on desktop)

Anyone else think of their day as a circle rather than a list?

Hi HN, I built py-sql-cleaner, a CLI for formatting SQL embedded in Python files.

Python formatters handle Python syntax. They do not format SQL written inside Python code. On the other hand, SQL formatters usually target SQL files or raw SQL text, not SQL embedded inside a Python file.

Still, I think it is not uncommon to find long SQL queries inside Python codebases.

py-sql-cleaner detects embedded SQL inside Python files and works only on that SQL. The main things it can do are: find the SQL, format it in place, or extract it into a .sql file.

It avoids rewriting SQL that depends on runtime values or template expansion. For example, SQL containing parameters like %s or :name, or Jinja-style template variables like {{ ds }}, is skipped by default.

Try it with:

    uvx py-sql-cleaner list path/to/file.py
    uvx py-sql-cleaner format path/to/file.py --dry-run

If you write Python, have run into this kind of SQL cleanup problem, or are just curious, I’d be happy if you take a look.

I've been building a cli for my homelab/self-hosted setup. The original motivation was getting tired of stitching together deployments, monitoring, remote SSH access and random scripts. It’s a open source CLI, all-in-one tool for monitoring, secure remote accces (tunnel and terminal), log forwarding, automated deployments. No exposed ports, or endpoint, everything is configurable how the user wants it. One use case that multiple friends are interested in is replacing HomeAssistant’s Nabu Casa subscription with tunneling through BeaconInfra. The cloud/control-plane part (BeaconInfra) is optional. The agent itself is intended to stay local-first and continue functioning offline. Example CLI output:

⬡ beacon 0.5.2 ● master running uptime 29d 14h

DEVICE bajszi-MINI-S amd64 Ubuntu 25.04

PROJECTS 2 healthy 0 warning 0 down

  ● beaconinfra        1/1 checks passing
  ● mestertkeresek     1/1 checks passing

TUNNELS

  ● homeassistant      connected

We built Multiplayer because we kept running into the same problem: coding agents connected to existing observability stacks inherit all the limitations those stacks were built with. Sampled traces, aggregated metrics, context that stops at service boundaries, missing request/response content from deep within the system. The PRs they produce look plausible and fail in production (i.e. “PR slop”).

Multiplayer runs locally alongside Claude Code (Codex, Copilot, and Cursor coming soon) and captures full-stack, unsampled session data across your entire system. We collect everything from frontend user actions to backend traces and logs, including request/response content and headers. It’s all the things most observability tools either sample out or don't capture at all. We only save data when something goes wrong, so you're not paying to store everything your system produces around the clock.

When an issue is identified, Multiplayer deduplicates it locally before anything reaches your coding agent. The same bug appearing across a hundred sessions becomes one issue, one prompt, one PR. Your agent works from a complete, correlated picture of what actually broke rather than a partial signal from a sampled trace.

We tried to make it as easy as possible to get started, so it’s just one command line to install:

`npm install -g @multiplayer-app/cli && multiplayer`

Happy to get into the architecture, the data model, or how we handle the local-first approach to data privacy.

Hi HN!

I'm the developer of OffChess a Hackernews favorite Chess puzzles app. About 6 months ago I saw someone reviewing an Apple TV 4k on their youtube channel and it looked vastly superior in terms of UI and UX to what Android based Google TVs provide. I asked the people over at r/AndroidTV if someone has ported Apple TV experience to Android TV and they said no. So I built a makeshift video and posted on Reddit. People there loved it and started sending me Reddit chat messages every day to build and launch it.

So it took me 3 months to solve all edge cases and I built and launched AT4K Launcher in January and people absolutely loved it. Since then BGR, Android Authority, Makeuseof and multiple tech websites have featured it as one of the best Android Launchers.

Clean, fast, minimal, pretty, no accounts, no tracking, no monthly subscriptions, no internet required. Just you and your apps. With Live wallpaper, custom app icons, icon packs support and multiple ways to modify your home screen AT4K Launcher packs everything you need in a neat ui.

Here is the play store link- https://play.google.com/store/apps/details?id=com.overdevs.a...

Would love feedback, bug reports, or suggestions.

Thanks!

Would appreciate a star (and happy for ideas on improving indexing speed/embedding quality)!

So we have had quiet the journey here.

So 70 days ago (aka 73 turns ago) I posted on HN sharing our FreeCiv deployment (https://github.com/ndroo/freeciv.andrewmcgrath.info). FreeCiv is a great game, the clients is very buggy however. I'm using the GTK4 version, but a few others have opted for the QT variant. At some point, we might turn our focus to contributing to improving the client based on our experiences playing the game.

We've since added a lot of little fun features:

- The editor: you can write to the newspaper Editor and they /might/ publish what you write, quote you, or decide you're full of it and write an opinion piece slamming your reputation. The editor will also reach out to a few players, each turn, and ask for their input on current game matters.

- The Intelligence Dashboard. People were forgetting what they were up to, so we added a dashboard showing the timeline of what happens per turn for your player.

- beta the online map viewer: I wanted a way to view the map without loading the client, so we started working on a beta map viewer that is HTML based.

- The Chronicle (The newspaper) has also grown a bit. Maybe too much? We'll see. The crossword is fun.

Some other 'fun' things that happened: my brother in law stopped speaking to me because of in game banter that was taken way too seriously. My friends invaded my wifes territory, and well, she didn't like that either.

I'm currently in the lead, but theres still a long way to go from 475BC.

Agent skills for working with VillageSQL. Skills run in Claude Code, Gemini CLI, agy, Codex, Cursor, Amp, and Kiro.

I built scrolodex to scratch my own itch of having a quick and simple way to switch between the currently open windows under my cursor.

Simply hold ⌥ + scroll to cycle through windows under your cursor. Release to focus.

Also includes triggers for scrolling through all windows, dock app's windows, or switching between desktop spaces. Configurable hotkeys, themes and overlays.

Completely free and OSS.

brew install --cask jaydenfyi/tap/scrolodex

Website/demo: https://scrolodex.app/ GitHub: https://github.com/jaydenfyi/scrolodex

I have spent the last few months working on infrastructure and tools to give agents global ids, and the ability to communicate.

That is up and running now, but actually structuring their work together has been a real pain: I still have to give them roles and responsibilities, and start the agents in the right directories with the right id so that the actually get things done.

I have automated that part now: a team can be bootstrapped from a template with one command:

aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git \ --username <name> \ --work-directory /path/to/your/repo

So far I have published three templates that I find useful (linked from the submitted github page).

I am looking for feedback, please let me know what you think and how to make it more useful. One direction I am considering is to replace the markdown-based structure with an actual ontology.

libfyaml 1.0.0-alpha7 adds an opt-in transparent parse cache for repeated reads of stable YAML/JSON files.

It is not making the parser itself hundreds of times faster. On a cache hit, libfyaml mmaps the generic arena and directly uses that instead of parsing the file. Due to the design of the generic subsystem it even avoids relocation and in 64bit systems with ASLR.

Benchmark run using the python binding on AllPrintings.json sized 427.5 MB.

- cache off: 16.98 s, +13.4 GB RSS - cold cache: 22.45 s, +13.4 GB RSS - hot cache: 35.9 ms, +1.0 MB RSS

That is about 473x faster on the hot-cache path versus a normal parse, with a much smaller memory delta. Also note how the RSS is essentially zero; the generic data in the arena are not even faulted in.

This is intended for startup/config/data-loading workloads where the same large YAML or JSON file is read repeatedly.

Benchmark commit: https://github.com/pantoniou/libfyaml/commit/f150432b36e409a...

Hey HN! We are back with new features in the open-source project, nxs-universal-chart. It's a Helm chart for deploying applications to Kubernetes/OpenShift. Instead of maintaining dozens of YAML files for each microservice, you define the configuration in a single values.yaml, and the chart renders the rest. In the new release, we expanded the chart ecosystem, reduced unnecessary synchronization, improved template rendering robustness, and increased efficiency and resilience of the tool.

New features:

• Added 11 OCI-hosted subcharts • Added MCP server for values.yaml generation and Helm chart validation • Added support for projected volumes and ServiceAccount imagePullSecrets • Adjusted autoRolloutChecksums behavior • Added GitHub Actions CI/CD out of the box • Fixed handling of null entries and rendering issues

We’re looking forward to your feedback, contributions and stars!

Feel free to join our Telegram community to share ideas, reports, or ask questions directly to the maintainers: https://t.me/nxs_universal_chart_chat