AI Meets You Where You Are

Most AI products ask you to come to them. Open our app. Upload your documents. Connect your accounts to our cloud. Retrain your team on our interface. Rewrite your runbooks as our prompts. Then, once everything you own has been moved into the shape the product prefers, the intelligence begins.

That is backwards. An organisation is not a blank page. It has tools it trusts, data where regulation and habit put it, people with uneven skills and real jobs, a slowly earned sense of what it will let a machine touch, and infrastructure it already pays for. Every one of those is a fact about where you are. A product that asks you to abandon them is not meeting you. It is asking you to move house so that it can visit.

The better posture is the one a good colleague takes on their first day. They learn your tools before suggesting new ones. They ask where the data lives rather than copying it somewhere convenient. They do small things well before asking for the keys. They work on your machines and bill to your account. The phrase for this is old and plain: meet people where they are. It is the design principle behind everything Juaji builds, and this note says what it means in practice.

Where you actually are

An organisation lives in five places at once, and an AI system has to arrive at each of them rather than summon you away from any.

1. Your tools. The command-line programs, containers, scripts and frameworks your team already runs and already trusts.
2. Your data. The databases, APIs and buckets where it sits today, under the access rules that already govern it.
3. Your people. The experts who know how the work is done, the juniors who are learning it, and the person who must answer for the result.
4. Your trust. How much you are prepared to let a machine do unsupervised, which is small on day one and grows only on evidence.
5. Your infrastructure. The machines you run, the model provider you have a contract with, and the budget line the work is charged to.

The rest of this note takes them in order. For each, it says what meeting you there looks like, and how Cazi, the harness Juaji builds, does it. Cazi is the worked example, not the point. Any system that respects these five places will feel like it arrived rather than like it summoned you.

Your tools: run what you already run

The first thing a new AI system should do with your tools is nothing. Not replace them, not wrap them in a proprietary “integration”, not ask for a rewrite in its own plugin format. Your security team trusts nmap. Your data team trusts duckdb. Your platform team has a container for everything. That trust was expensive, and a system that meets you keeps it.

The unit of work in Cazi is therefore a container image and a command, declared once as a template. If a tool runs in Docker, it runs in Cazi, unchanged: the same flags, the same output, the same version you pinned. A template for subfinder is three lines of YAML and the tool’s own documentation. There is no SDK to adopt and no adapter to maintain when the upstream changes.

The same holds one level up. If your team already builds agents in LangGraph, CrewAI or plain Python, those run inside Cazi as tasks too, in a golden image with the libraries installed and a model credential injected at claim time. The harness does not care what reasoning happens inside the box. It cares that the box is declared, scoped, recorded and stoppable.

And it holds for the place your people actually work. Cazi exposes itself as an MCP server, so a developer in Claude Code or Claude Desktop asks for a scan in a sentence and the harness runs the declared tool. Nobody opens a new console. The AI arrived in the editor that was already open.

Your data: connections, not migration

The second move most products ask for is the most expensive: send us your data. Upload the documents, sync the database, let us index the bucket. Once the copy exists, the product works beautifully and your data lives in two places, under two sets of rules, with the second set written by someone else.

Meeting you where your data is means the data does not move. Cazi holds connections, not copies: a PostgreSQL, MySQL or MongoDB database, or any API with an OpenAPI description, registered once with its credentials held in a vault. A task that needs one names it by reference. At the moment the task is claimed, the harness injects a credential into that container and nowhere else, and for a database connection it can mint a fresh, short-lived user that is revoked when the task ends.

Three things follow. Your data stays under the access rules that already govern it, because the harness is just another client of them. The model never sees a password, because the credential goes to the container, not to the prompt. And when regulation asks where a customer’s data went, the answer is nowhere: a tool read it, in place, under a named identity, and the record of that read is in the log.

The outputs are treated the same way. A task declares where its results go: a webhook you already run, your own S3 or MinIO bucket, a downstream task, a file. The harness routes to your plumbing rather than becoming a new place your data accumulates.

Your people: expertise carried, not replaced

A team is not one skill level. It has the engineer who knows exactly which flags make a scan safe, the analyst who has never run one, and the manager who will be asked why it was run at all. A product that addresses a single imagined user misses two of the three.

Meeting people where they are starts with the expert. Their knowledge is written down once, as a template that fixes how a tool runs and a skill that says when to reach for it and what to do with the result. From then on the junior and the model both inherit it. The analyst who asks for “a quick check of our external surface” gets the expert’s recon pipeline, with the expert’s flags, not an improvised command. The expertise has not been replaced by the AI; it has been multiplied through it.

It continues with the person who has to answer for the outcome. Nothing in Cazi is anonymous. Every task, pipeline, run and schedule carries who did it, on whose behalf, and by which door it came in. When an agent acts, the record names both the agent and the accountable person behind it. Juaji’s public principle is “human in the loop”, and the loop is this record, not a dialog box.

And it respects how careful people actually work. Before an agent or the assistant executes anything with a side effect, it must propose a plan: the steps, the tools, the risks, what success looks like. The plan is accepted or revised before the first container starts. That is how a senior engineer already works, in their head or in a ticket. The harness makes the habit mandatory for the one colleague who would otherwise skip it.

Your trust: small on day one, grown on evidence

No organisation trusts a new system on its first day, and none should. The mistake products make is to demand full trust up front: connect everything, grant everything, then you can always restrict it later. Later never comes, and the first incident is the first time anyone reads the permissions page.

Meeting you where your trust is means starting where you are, which is nearly zero, and giving you a way to extend it one proven step at a time. In Cazi an agent begins with no tools at all. Its allowlist is empty until a person adds to it, and each addition is pinned to a reviewed version of the agent. Its scope names the images it may run, the nodes it may run on, the connections it may read and the subjects it may act on, and anything outside that list is refused before a container is created. Delegation only narrows: an agent handing work to another cannot grant what it does not hold.

Around the scope sit the circuit breakers: turns, tokens, wall clock, spend, repeated failures, drift from the goal. When one trips, the run pauses and asks a person, rather than finishing badly on its own. The person who started the run can extend the budget and resume. That exchange, a few times over, is how trust actually grows: not by a settings screen, but by watching the system stop at the right moments.

The last piece is memory. Every failure is captured as a learning, and an agent may propose a root cause and a fix, but only a person promotes it to a warning or a block that acts on future work. The system gets more careful as it is used, at the pace you set, and never loosens its own leash.

Your infrastructure: your machines, your model, your ledger

The quietest demand a product makes is that the work happens on its machines, through its model, on its invoice. Each of those is a place you already are, and each is worth staying.

Your machines. Cazi is a single binary that runs a control plane, and the control plane can run its tasks on an embedded node, on a laptop, or on standalone nodes attached from other hosts, including the one in the network segment that must never leave the building. A task that needs a particular machine says so with a selector, and the scheduler sends it there. The containers run where your data and your compliance already are.

Your model. The harness has no model of its own and does not want one. You register the provider you already have a contract with, from a frontier API to a local server on your own hardware, and that is what the agents reason with. Switching providers is a change to a connection, not a migration. If a team’s data may not leave the country, the model that reads it does not have to either.

Your ledger. Every model call and every finished container is written to a cost ledger with the work still attached, so what did this run cost is a query, and it is answered in the currency and at the rates you set. Spend no rate covers is recorded as unpriced rather than free, so a figure is never understated. Budgets per tenant, person or agent warn or block through the same breaker a run already honours. The bill lands where your finance team already looks, itemised in your own terms.

All three say the same thing. The AI is a tenant of your infrastructure, not a landlord of a new one.

The meeting point

The meeting point: five places that stay where they are, one harness that arrives at each by a different door.

The organisation does not move. The harness arrives at each of its five places by a different door, and the model reasons behind the harness as the user at the prompt, never as the shell.

Why most products do not

Meeting people where they are is harder than making them move, and the difficulty is the whole explanation.

A product that owns the interface, the data copy and the model can be demonstrated in five minutes and controls every variable in the demo. A product that runs your containers, reads your databases in place and reasons with your provider has to work with every version of every tool you already have, and gets no credit for the parts that were yours. The glue is unglamorous. The vault integration, the per-task credential, the cost ledger in integer micros, the breaker that pauses at the right moment: none of it photographs well, and all of it is where the engineering goes.

There is also a commercial reason. Data that has been copied into a product is data that is expensive to take out again, and a team retrained on a proprietary interface is a team that will not leave. Asking you to move is a lock-in strategy dressed as onboarding. Meeting you where you are gives that up on purpose. You can leave Cazi with your templates, your containers, your data and your model exactly as they were, because they never became Cazi’s.

Juaji’s fourth principle is craftsmanship, and this is the form it takes here. The craft is in building the thing that fits the room it is placed in, rather than the thing that asks the room to change.

Seven questions to ask any AI product

The principle turns into a short interview. Ask these of any system that wants to work inside your organisation, including ours.

1. Can it run the tools we already run, unchanged, at the versions we pinned?
2. Does our data stay where it is, under the access rules we already have, or does a copy appear somewhere new?
3. Does the model ever see a credential, or does the credential go to the tool alone?
4. Can our most experienced person write down how a job is done once, so that everyone and everything else inherits it?
5. Does it start with nothing and let us grant one capability at a time, or does it ask for everything on day one?
6. When it is unsure, over budget or going in circles, does it stop and ask a person, and is that record kept?
7. Can it run on our machines, with our model provider, and tell us what each piece of work cost in our own currency?

A no to any of them is a place the product is asking you to move. Sometimes that move is worth it. It should at least be visible, and it should be your decision.

The measure

The measure of a good AI system is how little you had to change to use it well. Not how impressive the demo was, not how many tools it claims to have, but how much of your tooling, your data layout, your team’s habits, your risk posture and your infrastructure were still exactly where you left them a year later, with the AI working quietly among them.

That is a humbler ambition than “transform your organisation”, and a more useful one. Organisations are not transformed by software. They are helped by colleagues who learn how things are done here, do small things well, earn more, and keep a clear record. The best AI will be judged the way the best colleagues are. It will have met you where you were.

Noticed: all five doors are set by a person and none by the model. Whether that is the definition of a harness is a question for another note.

This is the fifth note in a series on Cazi, after Cazi: A Deterministic Harness for AI Agents, What an AI Agent Is, What an AI Harness Is and The Unix Philosophy in an Agentic Ecosystem.