Bring Your Own Agents

Back around 2016, at the design studio EETER, we were already using a semi-manual workflow to discover tenders, RFPs and other opportunities.

We used RSS readers and a few scripts that opened batches of listings in separate tabs. We improved the sources and filters over time, but the daily experience stayed fairly crude.

I would open one listing after another, scan it, realise it made little sense for us, close it, and continue. The setup helped us find things earlier. It still left me doing a repetitive qualification job that software should have handled.

Today, while testing Briifin, I still use several approaches.

I have notifications set up around the shortlist and specific search views. I also make time for browsing sessions because I want to see what the product is finding and where the filters still need work.

The long-term workflow should rely much more on saved views and notifications. Browsing still has a place, especially while exploring a new market, but I do not want Briifin to become another feed that expects people to scroll endlessly.

The filters should improve what reaches me. The workflow should help me spend serious time on fewer opportunities.

Getting every tender file

Once an opportunity looks possible, the next step is getting the complete source material.

The listing itself might contain a title, buyer, deadline, budget, and short description. The actual requirements can be spread across eight or ten attachments.

There may be annexes, pricing forms, draft contracts, reference requirements, submission templates, corrections, and a separate test exercise.

I remember finding a test exercise buried inside one of these document sets. Later, when I wanted to check it again, I could not find it. I had already seen it once and still lost time searching for it.

This is why I want Briifin’s MCP connection to handle the source files as well as the tender information.

The command I imagine using is:

/fetchfiles

I would run it from the folder where I want to assess the tender. It would use the currently selected Briifin opportunity, or ask for an opportunity ID if none is selected.

The command should:

• fetch every available source document
• preserve the original files
• create a manifest containing filenames, source links, dates, and download status
• unpack ZIP files without changing the originals
• inspect signed containers such as BDOC or ASiC-E files and extract their contents while preserving the original container
• make extracted text searchable
• check for updated or duplicate files
• report anything restricted, corrupted, missing, or impossible to open

If the source appears to contain ten documents and the agent retrieves seven, I want to know that before it writes a confident assessment.

At the moment, we are testing file retrieval and this workflow through Briifin’s MCP connection on a single data source.

Giving the agent our studio context

The tender pack explains what the buyer is asking for. The agent also needs to understand our studio.

For our own use, that context includes:

• who is currently available in our core lineup
• trusted contractors and potential candidates we can bring in
• what each person can credibly deliver
• which case studies support those capabilities
• our financial and eligibility constraints
• the kinds of projects we want
• our previous tender decisions and outcomes
• cases where we shortlisted something and later declined
• cases where we applied, lost, and received useful feedback
• the way I prefer assessments to be written

Most of this information already lives in our Notion workspace.

For our tender work, Notion is the human-maintained source. We export a smaller studio context pack from it. Giving an agent our entire Notion account adds unrelated material and makes it harder to know which information influenced the assessment.

The context pack contains a studio profile, current lineup, capability matrix, commercial constraints, relevant case studies, and tender history. It also includes trusted contractors and potential candidates we can approach to cover specific capacity or capability gaps. Each file shows when it was last updated.

The financial context stays narrow. The agent gets the turnover, insurance limits, commercial thresholds, payment-risk rules, and similar qualification information it needs. It does not get unrestricted access to every transaction or account.

For our setup, everything lives in a separate new-business folder:

new-business/
  studio-context/
  tenders/
    2026/
      tender-name/
        manifest.json
        source/
        extracted/
        executive-summary.md
        assessment.md
        decision.md
  tender-ledger.csv

Each tender has a stable folder. Its status and outcome are recorded in the decision file and the central ledger.

What I want from the assessment

Once the source pack and studio context are available, I want the agent to produce eight things:

1. An executive summary based on my instructions for length, writing style, level of detail, and source references. Plainspoken and direct, with none of those AI-generated walls of text.
2. A document check showing what was found and successfully opened, plus anything missing, restricted, corrupted, or trapped inside a signed container such as a BDOC or ASiC-E file. The agent should inspect the contents of these containers rather than treating the outer file as the document.
3. A submission checklist with deadlines, required files, formats, portals, and responsible people.
4. A bureaucracy and quirks check. This should catch exercises, mandatory forms, unusual declarations, signing requirements, and details such as every CV needing to be signed individually by the person concerned.
5. Hard eligibility blockers and questionable requirements that need closer assessment.
6. General delivery and capacity fit, including weaknesses in our core lineup and whether trusted contractors or potential candidates could credibly cover them.
7. A short economics check. This could estimate required hours or days, compare our normal rates with the available budget, include proposal effort and travel, and flag payment terms or assumptions that fail a basic sanity check.
8. A final decision section covering the strongest reason to pursue, the strongest case for declining, any questions that still require human judgment, and a provisional recommendation.

I do not need a mysterious 87 percent fit score. I need the reasoning, the source evidence, and the unresolved questions.

Why I am sceptical of built-in tender AI

Tender platforms are starting to add AI summaries, fit scores, insights, and bid assistants.

I am not against using AI in tender work. I am sceptical of a category-agnostic assistant presented as if it can simply “do the bid.” A general tender platform has to support everything from construction and hardware supply to design, marketing, and software development. Its assistant reduces very different kinds of work to a common workflow.

That creates a hard limit for creative and technical services proposals. Buyers are judging the team, the method, relevant experience, understanding of the problem, and quality of the thinking. Scope, uncertainty, collaboration, and delivery risk are all tied together. A stock template built for every procurement category cannot go far into any one of them.

The useful role for an agent is narrower and more demanding: follow our workflow, check the source pack, expose the quirks, test eligibility and economics, and connect the requirements to actual people and case studies. It should help with the specific parts I ask for, not process the whole tender behind an AI button or pour our material into a generic template.

That also requires more than a basic company profile. Our decisions depend on internal rates, availability, financial constraints, our core lineup, trusted contractors, previous losses, buyer feedback, case-study evidence, and how much unpaid proposal work an opportunity justifies.

Putting that context into another tender SaaS creates questions about retention, access, analytics, and model training. It also adds another token allowance, AI credit system, context setup, and document workspace to configure and pay for, even though we already use ChatGPT, Codex, and Claude.

Briifin can fit into the workflow instead: it supplies the opportunity data and source files, while the sensitive studio context stays with the tools we choose. Fewer vendors receive it, and Briifin can be clear about the part it plays.

Some material may not leave our own machines at all. The same folder-based workflow can use a locally hosted model after /fetchfiles collects the tender documents. The model may be slower or less capable, but the choice stays with the studio. Either way, Briifin does not need a copy of our internal context.

Choosing the model and checking the result

I also want control over how much model capability I use.

An obvious rejection can go through a quick first pass. A valuable or borderline tender deserves deeper reasoning with the strongest model available to me.

For a high-stakes decision, I can use Codex to inspect the complete workspace and prepare the assessment, then ask Claude’s strongest model to review the work. I can also reverse the order.

The second model could be asked to look specifically for:

• missed eligibility blockers
• unsupported assumptions
• incorrect calculations
• overlooked documents
• reasons the first assessment may be too optimistic

For a tender that could consume a week of proposal work, an independent second review is reasonable. I would rather spend additional model usage on a small number of uncertain decisions than run an expensive analysis on every listing in the feed.

A built-in tender assistant is usually designed around the platform’s own cost controls. That often means a lighter model and a fixed reasoning budget that is good enough to produce a plausible-looking summary. I cannot turn the intelligence to the maximum when a decision deserves it, and I may not even know which model produced the answer.

Using Briifin through MCP lets me choose the model and spend deeper reasoning on the opportunities where being wrong would be expensive.

The role I want Briifin to play

In my own workflow, Briifin would handle discovery, filtering, alerts, source links, and the complete tender document pack.

My studio context would stay in the workspace I control.

The agent would combine the two, produce the assessment, and save the decision. Later, the outcome would go into the tender ledger and become part of the context for future reviews.

That is the product direction I find safest, most honest, and most useful.

Briifin should help me reach fewer and more credible opportunities, then make it easy to bring the complete evidence into the AI workflow I already trust.