Metamodern Studio · Festina Lente
Questions before we build
Start with your process, the result you need and the decisions that must stay with people.
These answers explain how we frame a project; scope, access, cost and delivery are agreed for each engagement.
AI systems and agents
Does our business actually need an AI agent?+
Start with one recurring task, its users and the cost of mistakes. We compare an agent with simpler software or a human process, then agree what a useful pilot must demonstrate.
What is the difference between an agent, a chatbot and automation?+
A chatbot describes a conversational interface; an agent may also select tools and actions. A fixed workflow follows defined steps. We choose the amount of autonomy the task needs and make its boundaries explicit.
Can people approve an agent’s actions before they happen?+
Yes, approval can be part of the design. We agree which actions require confirmation, who can approve them and what happens after refusal. Permissions and action checks must also be enforced by the connected system.
Sources: OWASP — Prompt injection
How do you handle incorrect or invented AI answers?+
We test representative tasks, check source quality and define when the system must abstain or escalate. Important outputs need review. Retrieval and prompts can help, but they do not make an AI system infallible.
Can an assistant use our own documents and knowledge base?+
Potentially. We first inspect access rights, document quality and update rules. The pilot should show whether answers use relevant sources and respect each user’s permissions; uploading everything is not a starting requirement.
Sources: Anthropic — Building effective agents · OWASP — Prompt injection
How do you reduce prompt injection risks in connected agents?+
Treat retrieved pages and files as untrusted input. We limit tool permissions, validate actions outside the model and test hostile instructions. These controls reduce exposure; no prompt alone guarantees protection.
Sources: OWASP — Prompt injection
Design and creative production
What can a creative production project include?+
Depending on the brief: art direction, identity, imagery, films, motion design and format adaptations. We agree the deliverables, review stages and source files before production; AI is one possible technique.
How do you keep product details and brand identity accurate?+
We identify what must stay exact: geometry, labels, colours, claims or a person’s likeness. References and approval checkpoints guide production; outputs that distort important details need correction or another production method.
Can AI-generated assets be used commercially?+
It depends on the tool’s terms, input material and intended use. We document the production chain and review licences, likeness permissions and delivery rights. A provider’s commercial-use permission does not settle every third-party or copyright question.
Sources: Adobe — Firefly FAQ · U.S. Copyright Office — Copyright and AI
How are creative directions and revisions approved?+
Agree the brief, decision-makers and review stages first. We separate approval of a direction from final execution, collect consolidated feedback and clarify how changes affect scope before continuing.
Will we receive editable source files and reusable assets?+
We specify this in the proposal. Delivery can include approved exports, project files, reusable components and instructions. Third-party fonts, music, models or platforms may have separate licences or dependencies that must be listed.
Can you adapt creative work for several markets and accessible formats?+
We agree languages, formats and accessibility needs in the brief. Translation, subtitles, text expansion and local brand review need their own checks. A generated translation or automatic caption is a draft until reviewed.
Research, prototypes and XR
When should we commission research instead of a full build?+
When a material assumption remains uncertain: user need, technical feasibility, device support or economics. We define a question, a bounded experiment and a decision it should inform before committing to a larger build.
What is the difference between a prototype and a production system?+
A prototype tests a question under stated conditions. Production also needs agreed reliability, security, deployment, support and ownership. We document what has been demonstrated and what engineering remains before real operation.
Can an XR experience work in a browser without installing an app?+
For some experiences, yes. WebXR capabilities depend on the browser, device and requested features. We test the intended combination early and provide an appropriate fallback where the immersive mode is unavailable.
Sources: W3C — WebXR Device API
Will our XR prototype work on every headset and phone?+
That cannot be assumed. We agree target devices, browsers and interaction modes, then test them. Support for one device or a desktop demo does not prove support for another headset, phone or tracking feature.
Sources: W3C — WebXR Device API
How do you address XR comfort, safety and accessibility?+
We define the setting, session length, movement and exit controls, then test with intended users and devices. Comfort and accessibility require specific acceptance criteria; visual polish alone is not enough.
Sources: W3C — WebXR Device API · W3C — Web Content Accessibility Guidelines
What happens if a pilot shows that the idea should not proceed?+
That can be a useful result. We record the test conditions, findings and limitations, then recommend stopping, changing the approach or testing a narrower question. A pilot does not commit you to full development.
SaaS and integration
Should we buy existing software, integrate tools or build a custom product?+
We compare the workflow requirements, existing tools, access, total operating cost and future maintenance. Use configuration where it meets the need; integrate or build only where the remaining gap justifies the work.
Can you connect our CRM, documents and existing tools?+
We first check supported APIs, permissions, data formats and the actual workflow. A limited integration can test feasibility. Tool names alone do not establish access or compatibility; those are verified before committing to delivery.
What happens when an integration fails or receives the same event twice?+
We define retries, duplicate handling, logs and a recovery path for the specific services. Some providers deliver duplicate or out-of-order events, so the design must not treat every notification as a new business action.
Sources: Stripe — Webhook reliability
How are user roles and access permissions designed?+
We map who may view, edit, approve and operate each part of the workflow. Permissions must be enforced in the system and tested across roles, including denied actions; hiding a button is not an access-control policy.
Sources: OWASP — Prompt injection
Can another team maintain the product after delivery?+
That should be part of the scope. We agree repository access, documentation, environment setup, dependencies, licences and operating responsibilities. Handover is demonstrated by a practical acceptance exercise, not only a folder of files.
Who owns the code, data and third-party accounts?+
The agreement should distinguish client data, commissioned work, pre-existing components and third-party licences. We clarify account control, export and access at handover before work begins; ownership is not inferred from a service page.
Choosing a team and planning delivery
What should we send before the first discussion?+
Describe one process or project, its users, current tools, volume, constraints and the decision you need to make. Share a non-confidential example if possible. We use this to discuss fit and a sensible next step.
How much will the project cost?+
We estimate after agreeing the task, deliverables, access and acceptance criteria. The proposal should separate discovery, implementation, third-party usage and ongoing support. There is no reliable universal price for an undefined AI or design project.
How long will delivery take?+
Timing depends on scope, dependencies, review availability and what must be proved. We agree milestones and the responsibilities needed to meet them. A demo date is not automatically a commitment to a production-ready system.
How should we compare an AI or design partner?+
Compare relevant work, the exact role played, proposed controls, acceptance criteria and total delivery cost. Ask who will do the work and what evidence supports claimed results. Use the same brief when comparing proposals.
What happens when requirements change during the project?+
We assess the effect on deliverables, cost, dependencies and schedule before adding the work. A clear change decision protects useful progress and prevents an informal request from becoming an undisclosed commitment.
How do we know the project is ready to accept?+
We agree observable acceptance criteria before implementation: representative tasks, approved outputs, supported environments and known limits. The review should demonstrate the agreed behaviour and include failures or exclusions that affect real use.
Data, evidence and measurement
Can we use personal or confidential data in an AI project?+
Do not send them before access and handling rules are agreed. We examine the purpose, permissions, hosting, retention and provider terms with your responsible team. A prototype can often start with redacted or synthetic examples.
Do we need cloud AI, private hosting or local models?+
We compare the data constraints, quality needed, available hardware, operating skills and total cost. Local deployment can change exposure and control, but it does not by itself establish security, compliance or sufficient performance.
How do you measure whether AI has improved the workflow?+
Agree a baseline and comparable tasks first. Measure accepted output quality, full cost, cycle time, rework and human intervention. We report the observed result and its limits rather than extrapolating a demo into a guaranteed return.
Sources: NIST — AI Risk Management Framework
What ongoing costs should we budget beyond development?+
Depending on the system: model usage, hosting, storage, licences, monitoring, human review and maintenance. We estimate against expected volumes and define limits or alerts. A low model price does not describe the full cost of a workflow.
Can you guarantee visibility or recommendations in AI search?+
No. We can improve accessible pages, clear service descriptions, evidence and consistent identities, then monitor search performance and selected questions. Search systems decide inclusion; useful content and technical foundations support discovery without guaranteeing it.
Sources: Google Search Central — AI features and your website
Will adding an FAQ make us appear in Google’s FAQ rich results?+
No: Google stopped showing FAQ rich results on 7 May 2026. A useful FAQ can still answer customer questions. We maintain readable answers and accurate semantic markup without promising a special search display.
Sources: Google Search Central — Documentation updates · Schema.org — FAQPage
Discuss your workflow
Tell us the process, team, tools, volume, constraints and decision you need to make. We will discuss fit and agree a scope before work begins.
Opens your email application. Sending an enquiry starts a conversation; scope, fees and delivery dates are agreed together.
