Create an AI system register
List each internal and customer-facing use, its purpose, owner, provider, data sources and actions. Include unofficial tools used in daily work. Visibility is the foundation for every other control.
Classify systems by impact. A private brainstorming assistant does not require the same review as a system that approves a payment or communicates a binding decision.
Define data and vendor rules
Specify which information may enter third-party services, how it is retained and whether it is used for provider training. Review access, subprocessors and deletion options based on the sensitivity of the use case.
Avoid relying on brand reputation alone. Configuration and contract terms can materially change the risk of the same tool.
Evaluate and monitor
Create representative test cases and measurable acceptance criteria. Track quality, refusals, latency, cost and escalation. Re-evaluate after model, prompt, data or workflow changes.
Record important versions so unexpected behaviour can be investigated. AI governance should support faster safe iteration, not freeze the system indefinitely.
Assign human accountability
Name a product owner and a technical owner. Define when a person reviews an output, who can stop the system and how incidents are reported.
Wishmakers builds governance into product architecture and operations. Controls are most effective when they are part of the workflow rather than a document users must remember separately.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
Does every company need an AI policy?
Any company using AI benefits from clear rules proportionate to its data and risk.
Who should own AI governance?
Ownership is often shared across leadership, product, technology, security and legal roles, with one accountable decision-maker for each system.
How often should AI systems be reviewed?
Review frequency should reflect impact and rate of change. Material model or workflow updates should trigger a new evaluation.
Look for product judgement
Ask candidates to challenge the brief. A strong partner should identify the main user outcome, the riskiest assumptions and the smallest useful release. A team that agrees with every requested feature may be optimising for project size rather than product success.
Request examples of decisions, not just screenshots. What was removed? Which assumption changed? How did user evidence alter the roadmap? These answers reveal how a team thinks when information is incomplete.
Examine production capability
A polished prototype is not evidence of reliable engineering. Discuss authentication, data protection, testing, deployment, observability, backups and incident response. If AI is involved, add evaluation, fallback behaviour and cost monitoring.
Clarify who owns architecture and technical documentation. The system should remain understandable beyond the individuals who first built it.
Evaluate the working model
Good collaboration has explicit decision rights, a visible backlog and frequent demonstrations of working software. Ask how scope changes are handled and how risks are communicated. Silence until a large milestone is rarely a sign of control.
Commercial models should support learning. A staged engagement with clear outcomes can be safer than a large fixed commitment based on uncertain requirements.
Check alignment after launch
Products need operation, measurement and iteration. Establish whether the partner can support the launch and how knowledge will transfer to an internal team. Define service levels only where they match genuine business risk.
Wishmakers builds and operates products of its own. That operating exposure informs decisions about reliability, payments, users and the less visible work required to keep a digital product useful.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
What should I prepare for a first meeting?
Bring the user problem, business objective, constraints, existing systems and any evidence from customers. A feature-complete brief is not required.
Should I choose a specialist or a generalist?
Choose the team whose relevant experience reduces your main risk. Domain insight may matter more than a specific framework.
How can I compare proposals?
Compare assumptions, exclusions, team composition, delivery method, ownership, post-launch support and total expected cost, not just the headline price.
A demonstration follows the happy path
Prototypes are designed to make the central idea visible. They can rely on clean sample data, known user behaviour and manual intervention. Production systems face incomplete records, duplicate actions, interrupted payments, forgotten passwords and unexpected demand.
List the failure modes of the core journey before scaling. Decide what the user sees, what the system records and how the team recovers. Graceful failure is part of the product experience.
Quality must become measurable
Production teams need automated tests, release checks and monitoring. For AI systems, conventional tests are not enough because output quality may vary. Representative evaluations and thresholds must be defined for the tasks that matter.
Measure latency and cost as part of quality. An impressive result that takes too long or costs more than the user creates is not production-ready.
Security and operations become product features
Access control, encryption, backups, logs and dependency management affect trust. The appropriate level depends on the data and the consequence of failure, but these decisions cannot be postponed indefinitely.
Assign ownership for alerts, support and incidents. A dashboard without someone responsible for acting on it creates visibility, not resilience.
Use a production-readiness gate
Before launch, review users and permissions, data flows, integrations, error states, performance, monitoring, support, legal requirements and rollback procedures. Run the complete journey with realistic data.
Wishmakers treats operation as part of product design. Moving from a promising prototype to a dependable system requires coordinated product, engineering and business decisions.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering AI Systems
Frequently asked questions
Can a no-code prototype go into production?
Sometimes, if the platform meets the product’s security, scale, integration and ownership needs. The decision should be based on risk, not stigma.
What is production readiness?
It is the evidence that a system can serve intended users reliably, securely and supportably under realistic conditions.
Should every MVP be scalable?
It should support the next credible stage without unnecessary complexity. Designing for hypothetical global scale can delay learning.
Start with the workflow, not the model
Map the trigger, inputs, decisions, outputs, exceptions and owner of the current process. Observe what people actually do rather than relying only on the official procedure. Hidden spreadsheets and manual checks often contain the real business logic.
Choose a workflow with sufficient volume, a visible cost of delay and outcomes that can be assessed. Rare, ambiguous processes are difficult places to prove value.
Decide what AI should do
Use deterministic automation for stable rules and AI for tasks that involve language, images, classification or flexible judgement. Combining both creates more reliable systems than asking one model to control every step.
Set boundaries. The system may draft, extract, recommend, route or execute. Each level has a different risk. High-impact actions may need approval even when upstream work is automated.
Build the business case
Measure current handling time, volume, error rates, waiting time and rework. Estimate the realistic percentage that can be automated and include software, integration, review and maintenance costs.
Value may appear as capacity, faster response, consistency or increased conversion, not only headcount reduction. Select one primary metric so the pilot can produce a clear decision.
Move from pilot to operation
Test with representative cases and intentionally difficult exceptions. Monitor completion, escalation, quality, latency and cost. Keep an audit trail when the workflow affects customers, money or compliance.
Wishmakers connects AI, automation and conventional software into production systems. The aim is a workflow that does useful work under real conditions, not a disconnected demonstration.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
What processes are best for AI automation?
High-volume, repetitive workflows with digital inputs, clear outputs and measurable quality are usually strong candidates.
Does AI workflow automation replace employees?
It more often changes how time is allocated. People may focus on exceptions, relationships and decisions while the system handles preparation and repetition.
How long should a pilot run?
Long enough to cover representative cases and operational variation. Define the evidence threshold before starting.
What makes a system agentic
A conventional automation follows a predefined sequence. An agent can decide which step or tool to use based on context. Most dependable business systems combine both: fixed controls around a flexible reasoning component.
The term should describe behaviour, not marketing. If a system only generates text from one prompt, it is not meaningfully agentic. Tool use, state, decisions and feedback are the important elements.
Strong business use cases
Agents can gather and compare information, prepare account research, classify complex requests, coordinate content production or guide a user through a multistep task. They work best when actions are reversible and results can be checked.
Begin with an assistive role. Let the agent prepare a decision or complete low-risk steps before granting broader authority. Observed performance should determine autonomy.
Architecture for reliability
Define allowed tools, permissions, data sources, budgets and stopping conditions. Store the evidence behind important outputs. Use deterministic checks for critical rules and require confirmation before consequential external actions.
Evaluation should cover task completion, factual grounding, tool selection, security, latency and cost. A successful conversation is not enough if the underlying action is wrong.
The limit is part of the design
Agents should know when to ask, escalate or stop. This is not a weakness. It is how a product manages uncertainty responsibly.
Wishmakers builds AI systems around explicit jobs and operating constraints. The question is not how autonomous an agent can appear, but how reliably the whole system creates business value.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
AI Systems AI That Does Real Work
Frequently asked questions
What is the difference between an AI agent and a chatbot?
A chatbot primarily exchanges messages. An agent can select actions and use connected tools to advance a goal.
Can AI agents access company software?
Yes, through approved APIs or controlled interfaces. Permissions should follow least-privilege principles.
Are multi-agent systems always better?
No. Multiple agents add coordination and cost. Use them only when distinct roles improve quality or control.
Why human review exists
AI systems operate under uncertainty. A reviewer can resolve ambiguous inputs, protect high-impact decisions and provide feedback that improves the system. The need depends on the consequence of an error, not on how impressive the model appears.
Review also creates accountability. Customers and operators need to know who is responsible when an automated recommendation affects money, access or reputation.
Choose the right intervention point
Review can happen before an action, after a draft, only below a confidence threshold or through periodic sampling. Reviewing everything may destroy the economic benefit. Reviewing nothing may create unacceptable risk.
Segment cases by impact and uncertainty. Low-risk, high-confidence work can flow automatically. Exceptional or consequential cases should receive attention.
Design a useful review experience
Show the reviewer the input, proposed output, relevant evidence and reason for escalation. Make corrections fast and structured. A poor interface can shift work rather than reduce it.
Capture reviewer decisions as data. Patterns can reveal missing rules, weak sources or prompts that need improvement.
Measure the combined system
Evaluate end-to-end completion time, correction rate, escaped errors, reviewer workload and user outcome. Model accuracy alone does not describe whether the operating design works.
Wishmakers treats people, models and software as parts of one product system. The goal is not maximum automation. It is the best dependable outcome at a sustainable cost.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
Does human-in-the-loop prevent all AI errors?
No. It reduces selected risks when reviewers have enough context, time and authority.
When can review be removed?
When representative evidence shows that the residual risk is acceptable and monitoring can detect deterioration.
Can customers be part of the loop?
Yes. Confirmation, editable drafts and transparent choices can give users meaningful control.
Build the baseline
Record monthly volume, average handling time, labour cost, error and rework rates, waiting time and any revenue lost through delay. Use observed samples where possible. Estimates from memory tend to hide variation.
Separate touch time from elapsed time. Automation may not save many labour hours but can still reduce a three-day queue to minutes, which may improve conversion or customer satisfaction.
Estimate the addressable share
Not every case will be automated. Segment straightforward, complex and exceptional work. Apply a realistic automation rate and include human review for cases that need it.
Adoption matters as much as technical capability. If teams continue using the old process, theoretical savings will not appear. Include training, transition and governance.
Include total operating cost
Count discovery, development, integration, licences, model usage, infrastructure, monitoring, support and maintenance. Add the cost of correcting failed outputs. For AI workflows, usage cost can vary with input size and task complexity.
Compare costs across a defined period and include the cost of capital or payback expectation used by the business.
Track value after launch
A simple annual ROI formula is net annual benefit divided by total annual cost, multiplied by 100. Also calculate payback period and report the primary operational metric that creates the benefit.
Wishmakers designs measurement into the workflow so the business case can be tested with real usage. A successful automation should make its value visible in operation.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
What is a good automation payback period?
It depends on risk and company policy. Stable, low-risk automations may justify a longer period than experimental workflows.
Should time saved be counted as cash?
Only if the capacity is removed, redeployed or used to create measurable value. Report capacity and cash effects separately.
How do I value fewer errors?
Use the average cost of correction, refunds, lost revenue, compliance exposure or customer churn associated with each error type.
The agency model
Agencies are effective when the organisation knows what it needs and wants specialised delivery. Scope, budget and acceptance can be defined around a website, campaign, application or integration.
The client generally owns the business risk and product decisions. The agency is paid for its work whether the resulting product becomes a new growth engine or not, unless the contract creates a different incentive.
The venture studio model
A studio participates earlier in opportunity selection, validation, product design and operating strategy. It may contribute capital or capability in exchange for equity, revenue share or another form of long-term participation.
Because the studio shares risk, it must be selective. Evidence of market access, founder commitment and an unfair advantage matters as much as the idea.
Questions that reveal the right fit
Ask who owns the opportunity, who funds discovery, who makes product decisions and who will operate the product after launch. Determine whether the goal is a deliverable, an internal capability or a standalone venture.
If requirements are clear and ownership should remain entirely with the client, a product engineering engagement may fit better. If the opportunity is uncertain and both parties want shared upside, a venture model may be relevant.
A builder-operator perspective
Wishmakers builds products, supports ventures and operates digital businesses. That experience makes the operating model a first-class decision. A venture is not complete when the software launches. Distribution, support, economics and iteration determine whether it becomes a company.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
Does a venture studio always take equity?
No. Models vary and may include fees, equity, revenue share or combinations.
Is a software agency the same as a product company?
No. An agency primarily sells services. A product company creates and operates repeatable products for a market.
Can a corporate team work with a venture studio?
Yes, particularly when it needs an external team to validate and launch a new proposition with speed.
Start from an advantage
The strongest opportunities connect a meaningful customer problem with an asset the company can use unusually well: proprietary data, distribution, technical knowledge, trust or access to a regulated market.
Trend enthusiasm is not an advantage. Write a clear thesis explaining why this organisation is positioned to win and what evidence would disprove it.
Validate outside the corporate bubble
Interview and observe target users, but seek behavioural evidence. Test willingness to change, provide data, run a pilot or pay. Internal stakeholders are not a substitute for the market.
Use small experiments to test demand, feasibility and economics separately. Combining every uncertainty in one large build makes failure difficult to interpret.
Create suitable governance
The venture needs a senior sponsor, a small accountable team and fast access to decisions. Protect it from unnecessary process while preserving essential security, legal and brand controls.
Use staged funding tied to evidence. This creates discipline without forcing the team to predict a detailed multiyear roadmap before it understands the market.
Prepare for operation and scale
Decide early whether the venture will remain internal, become a separate entity or seek external capital. The answer affects technology, incentives, ownership and reporting.
Wishmakers combines venture thinking with product engineering and operation across its own portfolio. The objective is not an innovation theatre project. It is a credible path from opportunity to working business.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
How is corporate venture building different from innovation consulting?
Venture building includes creating and operating the product or business, not only recommending a strategy.
Should the venture use the parent company’s brand?
It depends on trust, audience and strategic intent. Brand architecture should be decided with market evidence.
What should the first stage produce?
A tested problem, target user, value proposition, key risk map and evidence-based recommendation for the next investment.
What the model includes
During build, the team validates requirements, designs the experience and creates the production system. During operate, it supports users, monitors performance and improves the product with real evidence. During transfer, knowledge, access and responsibility move to the internal team.
The phases should overlap. Documentation and internal participation cannot be postponed until the final week.
When it works well
The model fits organisations launching a new capability under time pressure, entering an unfamiliar technical domain or creating a venture before hiring a full team. It provides momentum while permanent roles are recruited.
It is less suitable when the organisation has no intention or capacity to own the product. In that case, a managed service or long-term operating partnership may be more honest.
Design transfer from day one
Define target roles, ownership, source code, infrastructure, data, vendor accounts, documentation and decision rights. Pair internal and external team members and schedule progressive responsibility shifts.
Measure transfer through demonstrated capability. The internal team should be able to deploy, diagnose and improve the product, not simply receive files.
Protect product continuity
Users should not experience the organisational transition. Keep one roadmap, one incident process and clear accountability throughout the handover.
Wishmakers’ concept-to-operation approach supports this continuity. Building the software and understanding its daily operation are two parts of the same product responsibility.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Capabilities Contact Wishmakers
Frequently asked questions
How long does a transfer take?
It depends on product complexity and internal readiness. Transfer planning should begin at project inception.
Can only part of the product be transferred?
Yes. Ownership can be divided across product, engineering, infrastructure and support when responsibilities are explicit.
What is the main risk?
A late, documentation-only handover that transfers assets without operational understanding.