Questions we get asked.

Yes. We use Fabric Airlift, our own migration accelerator, which composes Databricks Lakebridge for profiling, SQL conversion and reconciliation, then wraps it in scope acceptance, independent validation, signed migration certificates and a reversible cutover. Every converted artifact carries the tool version that produced it and the evidence that cleared it.

Deciding who can see what, proving it, and keeping lineage intact as data moves. In practice that means catalogue and schema design, grants that match how your teams actually work, and making sure the applications and agents you build inherit those permissions instead of routing around them.

Both. Applications that run in-workspace under their own service principal are a large part of what we do, using Databricks Apps, Unity AI Gateway, Model Serving and Genie. That is the difference between a lakehouse and a system people actually use.

Usually on the initiative that keeps slipping because your team is fully committed elsewhere. We take ownership of that piece without pulling anyone off the current roadmap, and we work in your workspace so nothing has to be handed back later.

Unity Catalog, Lakeflow, Delta, Databricks SQL, Databricks Apps, Model Serving, AI Gateway, Genie, Lakebase and Asset Bundles. Our accelerators are built on those same surfaces.

A feature calls a model. A system is everything that has to be true for that call to be trustworthy on the hundredth day: where the context comes from and how it is retrieved, what the agent is allowed to touch and under whose permissions, what happens when a step fails halfway, how you know an answer is still correct after someone changed a definition, and what it costs. The model is the part that is nearly free. The system is the part that decides whether it ships.

Usually the honest answer is that you need definitions before you need a graph. Andrew Ripley, who runs product here, describes most of the arguments he walks into as coming down to a definition: two teams mean different things by the same word, both are right, and the system is stuck between them. Most failures we see are not retrieval failures. They are two teams meaning different things by the same word, so both answers are correct and one of them is wrong to the person reading it. We start with the semantic layer, add structured relationships where questions genuinely span entities, and do not sell a graph to a problem that a definition would have fixed.

Yes, and that is the default. Applications and agents run in your workspace under their own service principal, inheriting Unity Catalog permissions. Hosting by us is available where it suits, but nothing about the architecture requires your data to move for it to be reasoned over.

An evaluation harness with ground truth you own. We sit with the people who already know the right answer, write the questions they actually ask, record what the answer should be, and run that suite against the system on every change. Without it you are relying on whoever last used it not to have hit the broken case.

We run our own company on one. GTM Brain is a production Databricks App that senses signals, judges accounts and drafts outreach under governed autonomy, with durable workflows and human approval gates. Fabric is a commercial product built on the same foundation, and across our clientele it has taken delivery work that needed a team of ten down to three.

Later than most people expect, and it is not usually the first problem. Optimisation of any kind, whether reinforcement learning on the model or an automated loop tuning the workflow around it, needs something to optimise against: a rubric that says what a good answer is and an environment that can score one. Almost every team we meet wants the optimisation and has neither. Build the rubric and the environment first, and you get most of the benefit from ordinary iteration; skip them and reinforcement learning is an expensive way to hillclimb a hill nobody has measured.

Both, in the same room, and that is the part we will not do at arm's length. Andrew Ripley, who runs product here, sits in those sessions for exactly this reason. The rubric encodes what your business considers a right answer, which is knowledge you have and we do not. Our job is to interrogate it until it is specific enough to score automatically, then build the environment that runs it. An engineer who has never sat with the people who own the question cannot write it, which is most of why we deploy forward.

A contractor takes a ticket. A forward-deployed engineer takes the problem. They sit with the people who have it, work out what is actually wrong, and build the fix. You are buying judgment about what to build, not hours against a specification someone else already wrote.

Days, not months. Our engineers average fifteen years of experience and have worked in unfamiliar enterprise codebases many times. The two-to-three week discovery exists so that ramp happens against a scoped piece of real work.

Yes. Continuity is the point. The team assigned to your project stays on your project and learns your systems, your data and your business context. We do not rotate people between accounts to balance utilisation.

Either, and the choice is yours. Our people can embed in your team, joining your standups, using your tools and reviewing your pull requests. Or we take the whole programme and run it as a full team from our own offices, delivering against outcomes while your team stays on its current roadmap. That second model is how we take on the larger builds, and plenty of engagements start as one and become the other.

Troy Busot, our CTO, puts it as drawing the permissions boundary in the first conversation, because giving an agent reach into production data before that line exists is an incident with a date on it. Concretely it is three things, in this order: a business problem stated precisely enough to argue with, that problem turned into a scoring rubric and an environment that can run it, and then the agent or workflow that scores well against it. Troy Busot, our CTO, is usually in the first of those conversations. The third used to be where the hundreds of hours went, and it is the part shrinking fastest, because good tooling now writes a great deal of it. The first two are not shrinking at all, because they require sitting with the people who own the problem and knowing what a right answer looks like to them. That is the work, and it is why we put senior people in the room.

Because the constraint moved rather than disappeared. When implementation was expensive, the scarce skill was building the thing. When implementation gets cheap, the scarce skill is deciding what should be built and being able to tell whether the result is right. A wrong goal now gets implemented faster than it used to. Our engagements have gone from ten people to three on exactly this basis: the three are the ones who can define the problem, write the rubric, and judge the output.

Both. Alongside software engineers we field product engineers, who decide what is worth building and cut the scope that is not, and design engineers, who make the thing usable. All three work as one team, and AI has made that team considerably smaller and faster than the equivalent staffing three years ago. Andrew Ripley runs product and Sam Salima runs design, both in house. Sam puts the design case as arriving while the engineering decisions are still open, since coming in after them leaves you decorating whatever was already decided badly.

Most start with a two-to-three week discovery, which gives you a scope, an architecture and a realistic cost before you commit to anything larger. From there we put the right team on it to get things done, with daily demos so you see working software every day. That might be a single embedded engineer or a pod that owns the programme outright.

The parts that decide whether a product is operable: an admin and operator console, tenant isolation enforced in the data layer, an audit trail of state changes, and the deployment path that gets releases out repeatedly.

Fabric Platform gives you a governed mutation pipeline, so every state change is policy-gated and auditable from day one instead of being retrofitted. Harness gives you a durable agent runtime. Those are months of foundation you do not have to write.

Yes. Everything we build for you is yours. Where an accelerator is involved we are explicit about which parts are ours and what it means for you to keep running them.

Yes, and we build new ones from scratch just as often. Greenfield and brownfield are both normal work here: a product that does not exist yet, or a system that does and needs extending, replatforming or rescuing. Discovery assesses what is already there before anyone proposes replacing it, so whether you extend or start fresh is decided on the evidence in front of us.

Any process with more than a few steps that must not half-complete: a payment that charges but does not fulfil, a repossession that starts but is never recorded, a pipeline that dies mid-run and leaves partial data. Temporal makes the workflow itself durable, so the process survives the infrastructure under it.

No. The usual pattern is to leave the services alone and put a workflow in front of the sequence that calls them. Your existing APIs become activities. That is how we migrate an existing job chain without a rewrite.

A queue gives you delivery. It does not give you the state of a business process. Temporal keeps a complete, replayable history of the workflow, so you can answer what happened, where it stopped and what compensating action ran, without reconstructing it from logs.

Yes, and it survives a restart. A workflow can park for days waiting on a signal, then continue from exactly where it stopped. We use that pattern in our own systems for anything that leaves the workspace.

Both. TechFabric is a Temporal partner and we have certified durable paths against Temporal Cloud, including a workflow that survived a full application restart and completed from its original history.

No. It is a library you register inside your own application, not a system you migrate onto. You start by routing one domain's mutations through it and expand from there.

An audit log records that something changed. This makes the change impossible unless a policy allowed it, and the event that explains why is emitted as part of the same transaction. You audit by running a query.

That is the reason it exists. An agent actor passes exactly the same policy and state-machine gates as a human one, with the same audit trail. There is no separate, weaker path for automation.

It is a feature-rich alpha. The local runtime, Temporal worker path, model provider registry, approvals, tasks, artifacts, metrics and Docker sandbox are used in controlled pilots and CI. Unattended production use is still being hardened, and we will tell you at the start of your engagement.

The same definition builds for a local Node runtime, a Temporal worker, a Cloudflare Worker, or a Databricks App running under its own service principal. You choose the target without rewriting the agent.

Tools resolve through Unity Catalog, so an agent's data access is bounded by the same grants as a human analyst's. It cannot reach what its service principal has no permission for.

It composes Databricks Lakebridge for profiling, analysis, SQL conversion and reconciliation, and adds source-specific transfer profiles on top. Synapse is one of the implemented routes; tell us your source and we will confirm what is covered today.

Cutover runs as checkpoint, apply, verify, with a defined path back out of an external change. A wave only cuts over once its certificate is issued, so the gate is the evidence itself.

That is the design goal. Every converted artifact is bound to immutable evidence and carries the tool version that produced it, so what was in scope, what proved it correct and who approved the wave are all answerable after the fact.

Yours. The control plane is a Databricks App inside your own workspace. TechFabric-hosted is available as an option, but in-workspace is the default so your data never leaves your boundary.

Promotion. An agent or model version only moves forward if its evaluation suite passes, and the gate is a policy checkpoint in the pipeline, and it holds when a release is late.

Every pull request gets one, with per-environment secrets synced to secret scopes. The point is that a change gets an environment before it gets an opinion.

Monitoring tells you a job failed. Radar carries declared service level objectives per workload, so it can tell you whether the breach matters, who is allowed to intervene, and what was actually done about it last time.

Restarting a job or rerouting a pipeline runs as a policy-checked action with an audit record, executed as a durable workflow. A fix at two in the morning stops being an untracked click in a terminal.

Telemetry ingest is deliberately append-only and stays outside the governed pipeline. Only state transitions pass through it, which keeps the audit trail meaningful instead of drowning in events.

One place to watch, steer and stop the work of an agent squad: a mission board, one-tap approval tickets, a runs ledger and shared documents, with the governance pipeline under every change.

No, and that is enforced structurally. Anything that would leave the workspace parks at a ticket that a person answers. The supervisor plans and routes; it never approves.

The mission resumes. The durable path is certified against Temporal Cloud: a mission parked at approval survived a full application stop and start, then completed from its original workflow history.

No. Databricks stays authoritative for compute, data, lineage and governance. Native MLflow runs are referenced rather than copied, so datasets, traces and artifacts stay where they are, and Experiments adds assignment, gates and cross-workload evidence on top.

Assignment, evaluation and quality gates run against your own Databricks data, so the comparison is mechanical. A failed evaluation blocks the promotion.

Yes. The same gates apply to an agent version as to a model version, which is what lets you ship agent changes at a pace without guessing at the effect.

Both. It runs TechFabric's own pipeline, which is what makes it honest evidence, and it is available to GTM teams who want the same loop.

Routine actions run on their own, but privileged ones like publishing, launching and sending need a tenant-issued, capability-scoped, expiring grant, and every send is revalidated at delivery. That is enforced in the pipeline, not asked for in a prompt.

Every organisation's data is scoped at the store rather than filtered in application code, so isolation does not depend on a query being written correctly.