BYOA: When Employees and Customers Bring Their Own Agents

Imagine your next employee arriving with an agent that helps them organise their work. Now imagine your next guest arriving with an agent that helps them organise their trip. How would your business work with both?

This is the question behind BYOA: Bring Your Own Agent. It gives us a useful way to explore what could happen when people choose an agent as their interface to services and work. Adoption will vary. Organisations can prepare by examining a few concrete workflows today.

Tourism makes the question tangible. An employee might ask an agent to prepare a partner meeting. A family might ask theirs to plan an afternoon around the weather, their interests and the time they have. Both need reliable information from the business. Both raise a question about what an agent should be allowed to do.

What an agent actually does

An AI agent combines a model with tools and a feedback loop. Given a goal, it can choose a next step, act through connected software, inspect the result and adjust. Its environment and permissions determine its reach. This explanation follows the architecture described in Anthropic’s guide to building effective agents.

A goal. A next step. A result to check. An adjustment.

For the travelling family, that could mean comparing activities, checking opening hours and replacing an option that no longer fits. Booking tickets would require a separate, authorised action. The system needs access to the relevant services for any of this to work.

“Own” also needs care. For an employee, the agent could be company-provided, configured for their role and used through approved connections. BYOA should leave room for personal working preferences within the organisation’s rules for data and access.

The employee: a meeting that does not start from zero

Consider an illustrative destination-management workflow. An employee needs to prepare for a meeting with a hotel partner. Useful context sits in earlier emails, meeting notes and a contact record. Finding it is work in its own right.

With approved access, an agent could assemble a short briefing and link each important statement to its source. It might flag an unresolved promise or a question that needs a decision. The employee checks the briefing and decides what deserves attention in the meeting.

Afterwards, the agent could turn approved notes into a draft follow-up and proposed record updates. The employee decides what gets sent or saved. Preparation, conversation and follow-through become one connected workflow.

That also changes how we might organise projects. When an agent handles a bounded execution task, a person can review another result while it runs. Planning, research, execution and review can happen in shorter loops, with feedback informing the next step.

Parallel work still has limits. Dependencies matter, and people need time to judge results. A useful pilot should measure the full workflow, including corrections and review, before claiming a time saving.

The customer: the guest brings context, you bring the place

Now consider a family with three hours, two children and an interest in local history. They want an afternoon that fits them. Their preferred agent could combine the preferences they choose to share with information from the destination.

The destination contributes what only it can maintain well: accurate opening hours, accessibility details, local stories and current service information. The agent could use that material to suggest a route, explain a landmark or adjust the plan when a venue closes.

This is a service-design scenario, rather than a report of a deployed guide. It asks us to consider an additional way for customers to reach the business. A destination’s website and app can serve people directly while selected information and services also become accessible through other interfaces.

The commercial question follows: if a request begins in the guest’s agent, can that agent understand what you offer and help the guest take the next step? Clear descriptions and current facts become part of the service. A beautifully written page with yesterday’s opening hours still creates a poor afternoon.

Guests should retain the choice to speak to a person. Good hospitality includes knowing when a conversation is more useful than another automated step.

Why this leads to Agentic Business Engineering

Coding agents can help write and change software. Connected agents can also use software to perform tasks, as the coding and computer-use examples in Anthropic’s guide demonstrate. Much of a business’s work already takes shape in software: its booking rules, approval steps and operational records.

Together, these capabilities create an opportunity to improve how a business works and build the systems that support it. Software remains only part of the business. Relationships, physical operations and accountability still need people.

At frontira, we use this definition:

Agentic Business Engineering is the discipline of redesigning work around the combined capabilities of humans, AI agents and software, and engineering the systems that make that work operational.

BYOA makes that definition concrete. The employee needs a useful way to work with an agent. The customer needs a dependable way to access a service through theirs. The business needs to decide how those interactions should work.

We describe four levels of capability and ownership:

1. Built for you. Specialists deliver a tailored tool that your team uses.
2. Operate through agents. Your team uses an agent to work with that tool.
3. Improve with agents. Your team changes rules or workflows with agent support and appropriate review.
4. Deliver yourselves. Your team builds new systems with agents and takes responsibility for operating them.

A tourism team might use a planning tool at the first level and later improve its rules at the third. These are choices about capability and responsibility, not a requirement to reach the fourth level. Different workflows may need different arrangements.

Permission is part of the product

An agent that can read a record should not automatically be able to change it. Define its access, require approval for consequential actions and record what it does. Enforce these boundaries in the connected systems, rather than relying on a prompt alone. These principles align with OWASP’s guidance on excessive agency.

For a BYOA service, make the questions explicit: whose agent is acting, on whose behalf, using which information, and with what authority? Give people a clear way to stop the process and take over.

One workflow is a useful beginning

Choose one recurring task with an outcome someone can check. The partner-meeting briefing is a good candidate for an initial experiment with approved information and no automatic sending.

Name an owner. Agree what a good result contains. Compare the complete effort with the existing process, including review and rework. Keep the parts that help and change the parts that fail. Expand access only when the evidence justifies it.

This is how I would approach the bleeding edge: close enough to understand the possibilities, with a limited cost of being wrong. Hands-on work gives the discussion substance. It reveals where an agent helps, where the process needs redesign and where human attention is essential.

Code the duty. Keep the beauty.

For tourism, the opportunity is to spend less effort assembling information and moving it between systems, while making more room for the welcome, the local story and the thoughtful response to an unexpected need.

BYOA asks businesses to become ready for people who may arrive with agents. We can begin by making one employee workflow better and one customer interaction easier, while keeping responsibility clear.

Which part of your work would you hand to an agent, and which part deserves more of you?

Explore Agentic Business Engineering with frontira.