Questions we get asked.

Yes. The first two weeks are the Migration Readiness Sprint at /databricks/migration-readiness. Fabric Airlift at /accelerators/fabric-airlift composes Databricks Lakebridge, then wraps conversion in signed certificates and a reversible cutover. If you already know the source, start at /databricks/from-snowflake, /databricks/from-synapse or /databricks/from-teradata.

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.

In practice they overlap, and pretending otherwise is how grants get retrofitted. We design the catalogue and the schema shape at the same time as the pipeline, so permissions and lineage are a property of the model rather than something added once the tables already exist. The separate governance line at /services/data-ai-governance exists for the cases where the estate is already built and the problem is defending it.

Yes, and it is common. The first work is usually reading what is actually running rather than what the documentation claims: which jobs matter, which tables nobody has queried in a year, and where the grain silently changes. That inventory is the same one the Migration Readiness Sprint at /databricks/migration-readiness produces, and it is worth having before anyone proposes a rewrite.

By treating cost as a design constraint rather than a monthly surprise. Cluster policies, sensible file sizes, and knowing which queries are actually paying for themselves. The two-week Databricks Health Check at /databricks/health-check is the named engagement when the bill is the question.

Lakeflow is enough for most pipelines. Temporal earns its place when a process spans systems and must not half-complete, or when a human approval sits in the middle of it and the workflow has to survive the wait. We are a Temporal partner and we use it where that property is worth the extra moving part, not everywhere.

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 nearly free. Whether the call ships is decided by the rest of that list.

Usually you need definitions before you need a graph. Andrew Ripley, who runs product here, walks into arguments that come down to a word two teams both use correctly and still cannot share. 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.

Usually because the model underneath is ambiguous rather than because the language model is bad. Two tables both hold something called revenue, the grain changes halfway through a table nobody documented, or an instruction says one thing and a column name implies another. Genie resolves that ambiguity silently and moves on. The fix is upstream of the prompt every time.

With a suite of benchmark questions that have known answers, run repeatedly rather than once at launch. That gives you a number that moves when someone renames a column, which is the only way to know accuracy is holding. The Genie Accuracy engagement at /databricks/genie-accuracy exists to build that suite and the definitions under it.

Not if the permissions are done properly, and this is the question worth asking early. Genie queries under the identity of the person asking, so row and column filters in Unity Catalog apply to the answer the same way they apply to a query. Where that boundary has not been drawn yet, it is governance work before it is Genie work, and it is at /services/data-ai-governance.

Yes, and they should read the same definitions. A dashboard answers the question everybody asks every Monday, and it should look identical every Monday. Genie answers the question somebody thought of in the meeting. Building them on separate definitions is how you end up with two numbers and an argument.

Less than teams expect on the serving itself and more than they expect on everything around it. The endpoint is straightforward. Reproducing the training set, moving feature computation somewhere that runs without one person's laptop, and deciding what happens when the model degrades are where the work actually is. That is usually two to six weeks depending on how the features were built.

On a schedule to begin with, because it is honest and it is cheap, then on a drift signal once there is enough production history to know what normal looks like. Retraining on drift before you can characterise drift produces a model that chases noise. Lakehouse Monitoring gives the inputs a baseline to be measured against.

Both, and the second is more common. Most teams we meet have a data scientist who has already found something that works and no path from there to an endpoint anyone will depend on. Where a model does need building, our engineers work alongside your data scientists rather than replacing them, because the domain knowledge that makes a feature useful is already in your building.

At the feature. Everything upstream of a feature definition is the pipeline work at /services/data-engineering, and treating them as separate projects is how a feature ends up computed twice with two different answers. We design the feature alongside the table it reads, for the same reason we design grants alongside the schema.

It is the substrate, not the answer. Turning it on gives you somewhere to express grants; it does not decide who should have them, whether lineage still resolves after a rebuild, or what an agent is allowed to touch. Most of the engagements we take start from a working Unity Catalog and an estate nobody can defend in a meeting.

The same way you govern a person, which is the point most teams miss. The agent runs under its own service principal and inherits Unity Catalog permissions rather than being handed a broad token. What it may do is a policy decision made before it is built, not a setting adjusted after something goes wrong. Fabric Tower at /accelerators/fabric-tower is what we use when a squad of agents needs watching rather than one.

Retrofitting it does. Designing it alongside the pipeline does not, and it is considerably cheaper than the alternative, which is discovering during a security review that the grants do not hold. We put the permissions boundary in the first architecture conversation for exactly that reason.

The first thing we establish is what is actually true: which grants exist, where lineage breaks, and what an examiner would find today. That inventory is quick, and it tells you what is reachable before the date rather than after it.

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, draws 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. He is usually in that conversation. What comes out of it, in order: a business problem stated precisely enough to argue with, that problem turned into a scoring rubric and an environment that can run it, then the agent or workflow that scores well against it. Tooling now writes a great deal of the third. The first two still require sitting with the people who own the problem and knowing what a right answer looks like to them.

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.

Twenty-seven, each with an executable playbook. Snowflake, Azure Synapse and Teradata have their own pages at /databricks/from-snowflake, /databricks/from-synapse and /databricks/from-teradata. Redshift, Oracle, SQL Server, BigQuery, Netezza and SAP are covered too. Tell us your source and we will confirm what the playbook does 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. If you are not sure the workspace is worth that yet, the Databricks Health Check at /databricks/health-check is the two-week way in.

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. When the thing being scored is a Genie space that executives have already stopped trusting, the named engagement is Genie Accuracy at /databricks/genie-accuracy.

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.