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 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 rather than as unbilled onboarding.

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.

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 rather than merely functional. All three work as one team, and AI has made that team considerably smaller and faster than the equivalent staffing three years ago. We have a Director of Product and a Director of Design, not a subcontracted design partner.

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 rather than status reports. 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 rather than filtered in application code, 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.

Often. We work on top of what exists rather than requiring a greenfield rebuild, and most engagements begin with a discovery that assesses the current system before anyone proposes replacing it.

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. Audit becomes a query rather than a reconstruction.

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 say so on your engagement rather than after it.

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 evidence rather than a status field someone ticked.

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 rather than a step someone can skip 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 rather than a judgement call. 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.