LA Metro: Ambient turns the Los Angeles rail network into a generative music instrument. Every note you hear is a real train arriving at a real station right now. Each of the six rail lines and two BRT lines has its own synthesizer voice. The piece evolves throughout the day as trains and buses come online and go offline, becoming dense during rush hour and more spacious late at night. The piece is ever changing and no two days are the same.
Fast is probably going to get in the way of Good, but here are some things to think about.
1. In many businesses, different users of the agent should have different read/write permissions to data.
2. Log everything. There will be problems. You'll need to debug, attribute, defend yourself against accusations that the cockup was your fault, etc.
3. If you're just providing read-only then the more you can enforce that at all layers of the stack (e.g., read-only user in the database).
4. Don't give the agent direct SQL access to the database. Write functions in your favourite programming language, expose them as tools to the LLM.
5. Don't make your LLM do maths in its head, they're crap at it. I had some success giving the agent tools that fetch data from the database (where I control the SQL that runs) into a SQLite in agent memory, then the agent can run SQL against that database. Gives you a chance to put the data into an obvious, easy to query, format rather than whatever arcane historic chaotic state your main schema has evolved to).
Thank you so much...
One doubt I have is when we expose tools instead of this raw sql, how do ensure that agents are using the correct data like right source and not stale.
Do we have to enforce some checks manually or is it not worth to worry(now it's read only right).
And one more doubt, what's the reason u introduced a lite layer in between?
I’m dealing with invoices and customers and timesheets and tickets. I didn’t want to give an agent SQL access to the database for performance and security reasons, and we don’t have a read only replica (which would have been much more acceptable to give read access to). So my tools are get_invoices etc. and they pull data into the SQLite.
My use case is a short conversation to answer a question like “has all the time from this task been invoiced?” Or “what contributed to the size of this invoice!”. So my agent starts with empty SQLite, fetches the data into SQLite, writes queries to answer the question, then user can continue to interrogate but eventually shuts down.
I don’t have a perpetually running agent so I haven’t had to solve that problem.
What could go wrong? Delete production data. Corrupt production data. Show staff member info they shouldn’t have. Show customer info they shouldn’t have. Rely too much on the LLM doing the right thing, it doesn’t, and the agent presents the wrong information without knowing. Bugger up the security and anyone can use the agent to query production data. … Yeah, be cautious.
Nice! Claude and I made something for my use called 'azdo' that's the 'gh' CLI but for Azure DevOps. I figured agents know how to use gh, so give them what they know. I haven't yet tried aliasing so they don't (at first) know it's Azure DevOps but that's coming ...
Being able to mange context over long running sessions is a function of the harness, not the model. Are you using Claude Code with GPT5.5? Codex? piclaw? They’ll all have different context management strategies to let you keep going when you would otherwise have filled up context and be forced to stop.
It doesn’t matter how good the harness is if the model does a bad job of planning and continuing from long context. A good harness cannot overcome a weak model.
This repo's README explains how it works and you can do it yourself. claude looks for environment variables that say which API endpoint to talk to, which key to pass, which model name to use for haiku/sonnet/opus-level workloads, etc.
Nice! Your spec-maxxing is very resonant. I've been doing working with explicit requirements: elicit them from conversation with me or introspecting another piece of software; one-shot from them; and keep them up-to-date as I do the "old man shouts at Claude" iterations after whatever one-shotting came up with.
Unlike you, I wish for the LLM to do as much of the work as possible -- but "as possible" is doing a lot of work in that sentence. I'm still trying to get clear on exactly where I am needed and where Opus and iterations will get there eventually.
It has really challenged me to get clearer on what a requirement is vs a constraint (e.g., "you don't get to reinvent the database schema, we're building part of a larger system"). And I still battle with when and how to specify UI behaviours: so much UI is implicit, and it seems quite daunting to have to specify so much to get it working. I have new respect for whoever wrote the undoubtedly bajillion tests for Flutter and other UI toolkits.
Forgot to add: I get several benefits from doing this.
1. Specifications that live outside the code. We have a lot of code for which "what should this do?" is a subjective answer, because "what was this written to do?" is either oral legend or lost in time. As future Claude sessions add new features, this is how Claude can remember what was intentional in the existing code and what were accidents of implementation. And they're useful for documenters, support, etc.
2. Specifications that stay up to date as code is written. No spec survives first contact with the enemy (implementation in the real world). "Huh, there are TWO statuses for Missing orders, but we wrote this assuming just one. How do we display them? Which are we setting or is it configurable?" etc. Implementer finds things the specifier got wrong about reality, things the specifier missed that need to be specified/decided, and testing finds what they both missed.
I have a colleague working on saving architecture decisions, and his description of it feels like a higher-abstraction version of my saving and maintaining requirements.
Specifications doesn't tell you what to do, they say what the end state should be. In between that you need a codebase analysis step and an implementation plan.
I do (1) the same but (2) differently. In my workflow, (2) are AI generated specs using human written (1) as the input. It's an intermediate stage between (1) and the codebase, allowing for a gradual token expansion from 30k to 250k to the final code which is 2-3M. The benefit I've found with this approach is it gives the AI a way to iterate on the details of whole system in one context window, whereas fitting the whole codebase into one prompt is impossible. The code is then nothing more than a style transfer from (2).
I'm not trying to convert you, just want to share process tips that I see working for me and others. We're using agents, not a chat, because they can do complex work in pursuit of a goal.
1. Make artifacts. If you're doing research into a tech, or a hypothesis, then fire off subagents to explore different parts of the problem space, each reporting back into a doc. Then another agent synthesizes the docs into a conclusion/report.
2. Require citations. "Use these trusted sources. Cite trusted sources for each claim. Cite with enough context that it's clear your citations supports the claim, and refuse to cite if the citation doesn't support the claim."
3. Review. This lets you then fire off a subagent to review the synthesis. It can have its own prompt: look for confirming and disconfirming evidence, don't trust uncited claims. If you find it making conflation mistakes, figure out at what stage and why, and adjust your process to get in front of them.
4. Manage your context. LLM only has a fixed context size ("chat length") and facts & instructions at the front of that tend to be better hewn to than things at the end. Subagents are a way of managing that context to get more from a single run. Artifacts like notebooks or records of subagent output move content outside the context so you can pick up in a new session ("chat") and continue the work.
It's less fun that just having a chat with ChatGPT. I find that I get much better quality results using these techniques. Hope this helps! If you're not interested in doing this (too much like work, and you already have something that works), it's no skin off my nose. All the best!
