—   MARCELUS FERNANDES · TECHNICAL KNOWLEDGE SUMMARY

I work where model capability becomes product behaviour.

I work where model capability becomes product behaviour.

My technical depth sits in the model-behaviour, inference and harness layer: the state a model sees, the memory it carries, the tools it may exercise, the evaluation system that measures it, and the operational constraints that let a probabilistic component become a dependable product.

My technical depth sits in the model-behaviour, inference and harness layer: the state a model sees, the memory it carries, the tools it may exercise, the evaluation system that measures it, and the operational constraints that let a probabilistic component become a dependable product.

Model behaviour

SPECIFY · OBSERVE · CHANGE

Evals and testing

MEASURE · CALIBRATE · GATE

Agent workflows

ORCHESTRATE · CONSTRAIN · RECOVER

Product leadership

DIRECT · TRANSLATE · DEVELOP

A model is one component inside a behavioural system.

A model is one component inside a behavioural system.

Product behaviour emerges from the model, prompt, state, history, retrieval, tools, routing, policies, channel and evaluation loop acting together.

I am not designing around AI. I am working on the mechanisms that determine the system behavior.

I am not designing around AI. I am working on the mechanisms that determine the system behavior.

I currently lead AI initiatives at AB InBev and work hands-on in Python and TypeScript through AI-assisted engineering. My ownership spans behavioural boundaries, agent architecture, the evaluation programme, retrieval quality, safety, observability requirements, and the operating model around the team.

14+ years in product and design are the substrate. I have led a 26-person design organisation, worked as a Principal and Staff designer, shipped zero-to-one products, and built operating systems. The tools changed. The responsibility did not: make complex systems legible enough to shape with intent.

Model behaviour, inference and harness

Model behaviour, inference and harness

State, context, memory, tool contracts, agent loops, retrieval, routing, evals, judges, safety, provider semantics, observability and iteration.

MY PRIMARY HANDS-ON WORKING LAYER

Application and operations

Channels, interfaces, integrations, product flows, deployment constraints, support operations and business outcomes.

BUILT AND LED, BUT NOT THE DIFFERENTIATING CLAIM

01 · TECHNICAL KNOWLEDGE

What I can work on in depth

What I can work on in depth

Eight connected areas form my working model of an AI product. The boundaries between them matter more than the labels: most failures emerge where one subsystem hands behaviour to another.

01

Model behaviour and state design

Model behaviour and state design

What should the system do, and what history teaches it to do next?

I specify behaviour as actions and transitions, not only tone. That includes when an agent acts, asks, escalates, refuses or defers; how uncertainty changes capability; and how past turns become behavioural precedent.

I specify behaviour as actions and transitions, not only tone. That includes when an agent acts, asks, escalates, refuses or defers; how uncertainty changes capability; and how past turns become behavioural precedent.

02

Context, memory and identity

Context, memory and identity

What must the model see now, what should survive, and what must be forgotten?

I treat context as a scarce behavioural budget. Stable instructions, contextual state and volatile turn data have different lifetimes and caching properties.

I treat context as a scarce behavioural budget. Stable instructions, contextual state and volatile turn data have different lifetimes and caching properties.

03

Evaluation systems

Evaluation systems

How do we know behaviour improved, and whether the instrument itself is trustworthy?

I design evals as measurement systems, not score dashboards: dataset contracts, isolation level, rubrics, verdict rules, repeated runs and calibration.

I design evals as measurement systems, not score dashboards: dataset contracts, isolation level, rubrics, verdict rules, repeated runs and calibration.

04

Agent workflows and orchestration

Agent workflows and orchestration

Which steps require model judgement, which require code, and how does work retain lineage?

I design agent systems as controlled compositions of probabilistic and deterministic operations, each with a clear accountable boundary.

I design agent systems as controlled compositions of probabilistic and deterministic operations, each with a clear accountable boundary.

05

Retrieval and grounding

Retrieval and grounding

How do we maximise useful recall without letting ranking, business logic or generation corrupt relevance?

I work with retrieval as a multi-stage decision system. Query intent determines the path; heterogeneous recall sources contribute candidates; rank fusion avoids comparing incompatible score scales; reranking adds pairwise relevance; business constraints operate only inside explicit semantic bounds.

I work with retrieval as a multi-stage decision system. Query intent determines the path; heterogeneous recall sources contribute candidates; rank fusion avoids comparing incompatible score scales; reranking adds pairwise relevance; business constraints operate only inside explicit semantic bounds.

06

Safety and capability boundaries

Safety and capability boundaries

What must the model never decide alone, and where must policy become architecture?

I separate prompt guidance from machine-enforced control. Safety spans input classification, route topology, tool authorisation, output verification, credential isolation, data minimisation and recovery behaviour. A component-level pass is not enough when an exception path can downgrade the system verdict.

I separate prompt guidance from machine-enforced control. Safety spans input classification, route topology, tool authorisation, output verification, credential isolation, data minimisation and recovery behaviour. A component-level pass is not enough when an exception path can downgrade the system verdict.

07

Model and provider operations

Model and provider operations

What changes when the model, provider or inference surface changes?

I do not treat Anthropic Messages, OpenAI Responses, Chat Completions and cloud inference surfaces as interchangeable transports. They differ in tool schemas, structured output, caching, reasoning-state continuity, error shape, token accounting and retry behaviour. Those differences belong in a capability layer, not scattered through callers.

I do not treat Anthropic Messages, OpenAI Responses, Chat Completions and cloud inference surfaces as interchangeable transports. They differ in tool schemas, structured output, caching, reasoning-state continuity, error shape, token accounting and retry behaviour. Those differences belong in a capability layer, not scattered through callers.

08

Observability and unit economics

Observability and unit economics

Can the team locate a failure, explain a cost change and protect the data needed to learn?

I specify observability around decisions, not only requests. A useful trace identifies the node, model, prompt version, tools, latency, tokens, cache behaviour, safety route and outcome while redacting the content a team does not need. Economics should follow completed tasks, including retries and rework, rather than flatter the system with cost per call.

I specify observability around decisions, not only requests. A useful trace identifies the node, model, prompt version, tools, latency, tokens, cache behaviour, safety route and outcome while redacting the content a team does not need. Economics should follow completed tasks, including retries and rework, rather than flatter the system with cost per call.

02 · TECHNICAL JUDGEMENT

The opinions behind the implementation

The opinions behind the implementation

Tools change quickly. These are the principles I use to decide what belongs in prompts, code, data, policy and team practice.

01   Prompts guide. Architecture controls.

If a rule matters, it must exist in authorisation, routing, validation or an invariant. A prompt-only constraint is a preference the model may ignore.

02   State is part of the experience.

What a system remembers, forgets and presents as precedent changes behaviour as much as the visible response.

03   Evaluate the evaluator.

A judge is a measuring instrument. Before it gates a launch, its variance, bias, schema, rationale-verdict consistency and hard classes need their own evaluation.

04   Use probability for judgement, code for invariants.

Semantic quality often needs a model. Credential absence, tool permission, schema validity, price evidence and route downgrade should not be scored. They should be enforced.

05 Preserve failed attempts.

Negative results, regressions and rejected mechanisms are part of the knowledge system. Removing them makes a team repeat expensive loops and overestimate certainty.

06 Complexity must earn its place.

More agents, routes, memories or judges create more failure surfaces. They stay only when an ablation, operational constraint or clear product boundary justifies them.

03 · EVIDENCE INDEX

Where this knowledge is implemented

Where this knowledge is implemented

The systems are evidence, not the organising structure. Each one exposes a different part of the same technical practice.

The systems are evidence, not the organising structure. Each one exposes a different part of the same technical practice.

SYSTEM

TECHNICAL TERRITORY

INSPECTABLE ARTIFACTS

Conversational agents (NDA)

Production agent architecture, state, context, tool traces, behaviour campaigns, evals, retrieval, safety, model routing and observability requirements.

Graph and state contracts · eval datasets · judge schemas · documented campaigns · safety regressions · retrieval architecture

Lohra

Inference runtime, provider semantics, opaque reasoning-state continuity, prompt snapshots, compaction lineage, orchestration, workflow DSL and capability security.

Agent loop · provider adapters · session lineage · typed operators · sandbox paths · extensive invariant suite

Laura

Longitudinal behaviour, canonical identity, surface policy, episodic and durable memory, context rotation, relationship-specific behaviour and response timing.

Behaviour audit · identity contract · policy map · memory jobs · runtime histories · pacing tests

Synthetic Users / PHB

Intermediate behavioural representation, explicit trace, context-to-state propagation, experimental design, criteria fixed before the runs, baselines and falsification.

Session traces · adversarial audits · negative and partial results · documented limitations

Upstream Agents (NDA)

Context engineering, cognitive decomposition, external memory, named inputs, model routing, deterministic validation and human gates.

Pipeline DAG · agent contracts · templates · validators · architecture self-audit

04 · SCOPE AND TRAJECTORY

What I claim, and what comes next

What I claim, and what comes next

Technical credibility means being precise about what I have built, how I built it and where I am going deeper.

Technical credibility means being precise about what I have built, how I built it and where I am going deeper.

01 I have not yet trained or fine-tuned a model.

My hands-on work so far sits in model behaviour, inference and the harness. Training and post-training are my next frontier, not a boundary I intend to keep. I already work with datasets, failure classes and evaluation, which gives me a concrete bridge into training architecture, data mixtures, optimisation and reward design.

02 I implement and ship code, with AI and with teams.

I implemented and evolved an AI copilot in production, including its first end-to-end prototype, search engine, catalogue enrichment and application-level evals. I use AI-assisted engineering extensively and work with engineers, but I read, review, change and ship code. My claim is hands-on system direction and implementation, not lone-wolf authorship.

03 I separate knowledge from maturity.

Production, pilot and side-project evidence are not equivalent. I can explain which mechanisms have met real traffic, which are tested invariants and which remain research hypotheses.

05 · PUBLIC WORK

Ideas that can be inspected

Ideas that can be inspected

Public artifacts carry the technical thesis outside private systems and employer context.

Reasoning Environments

Open thesis, MIT license. Six principles arguing that LLM reliability is a property of the environment, not of the model alone.

Open thesis, MIT license. Six principles arguing that LLM reliability is a property of the environment, not of the model alone.

The AI PM Test

Judge calibration, retrieval versus generation failure, cost per completed task and autonomy as an explicit risk decision.

Judge calibration, retrieval versus generation failure, cost per completed task and autonomy as an explicit risk decision.

Synthetic Users / PHB

A traceable behavioural representation with evaluation criteria fixed in advance, adversarial audit, partial results and visible limitations.

A traceable behavioural representation with evaluation criteria fixed in advance, adversarial audit, partial results and visible limitations.

—   MARCELUS FERNANDES

Design leadership with technical depth at the behaviour layer.

Design leadership with technical depth at the behaviour layer.

Happy to go deeper on any mechanism above, including what I would expect engineers or scientists to own.

mxrcelus@gmail.com

linkedin.com/in/marcelusfernandes

Technical knowledge summary · August 2026

Technical knowledge summary · August 2026

Behaviour · Evals · Workflows · Context · Retrieval · Safety · Operations

Behaviour · Evals · Workflows · Context · Retrieval · Safety · Operations