Arsen Hrynevych

Menu

Start with the work people need to do.

I’m a developer and Technical Lead. I work with customers to understand what’s worth building, shape how people use it, and lead the engineering behind it.

See selected work View CV
Product vision, engineering, people and deliveryThree connected layers representing the areas of responsibility in my work.Product visionEngineeringPeople & delivery Product vision, engineering, people and deliveryThree connected layers of responsibility with space between product vision, engineering, and people and delivery.Product visionEngineeringPeople & delivery

Selected work

The following cases come from my work on an enterprise AI platform at Manifold AI. Each covers a different decision I took responsibility for.

01
Product direction

Defining the product’s next stage

Problem
We had built different agents and capabilities, but they weren’t coming together as one product. The agents’ baseline needed improving, and we needed a clearer picture of how those capabilities should work together for customers.
What I did
I developed a strategy for the next stage of the product. It connected improvements to the agents’ baseline with the customer experience we wanted to build, and set out the engineering work needed to get there. I turned that direction into a phased roadmap and presented it across the company.
Result
The team now uses that strategy to guide the product’s development.
Connected priorities for the product’s next stage
  • Strengthen the agent baseline

    Establish a consistent foundation for agents.

  • Connect the product’s capabilities

    Connect existing capabilities around customer needs.

  • Guide customers through the experience

    Help people understand how to use the product.

Key decisions

What changed my view

I’d supported the “virtual colleague” framing. As larger vendors made agent capabilities easier to obtain, I stopped seeing the agent itself as a reason to choose our product.

Connecting the features

We already had tools and conversation channels. The strategy linked the customer experience with the engineering work needed to support it, instead of adding features without a shared purpose.

What a project leaves behind

Each customer project should raise the platform’s baseline: keep capabilities other customers need, and keep customer-specific work separate. We agreed on that priority.

Keeping it current

I keep researching competitors and reviewing customer feedback. We change the roadmap as we test our assumptions.

02
Platform engineering

Establishing a shared baseline for agent development

Problem
We already had an agent service, but building an agent still involved substantial work on its tools, instructions and behaviour. Growing demand made those development cycles too expensive to repeat.
What I did
I defined a common agent structure and introduced reusable skills, including onboarding. Agent roles and structured configuration made defining instructions more systematic. The foundation established what an agent should already have, leaving customer-specific tools and requirements to shape the individual agent.
Result
More of the work now centres on defining the agent’s job and building the tools it needs, rather than repeatedly establishing its baseline.
How the agent architecture changed
Before
Agent A
Orchestration
Tool access
Context
Agent B
Orchestration
Tool access
Context

Core capabilities adapted per agent

After
Agent Aits workflow
Agent Bits workflow
Shared agent coreOrchestration, integrations, memory, retrieval and tool execution

Agent-specific tools and configuration

Conceptual diagram with illustrative agents.

Key decisions

What belongs in the baseline

The baseline defines how an agent is structured and which reusable skills it starts with. Its role and instructions are configured for the job. Customer-specific tools and workflows remain separate where they aren’t useful to other agents.

When not to generalize

I move work into the foundation only when several agents need it. A niche CRM integration can stay specific to one customer.

Supporting agent development

An agent-development assistant gathers context and helps build new agents. It is already used in our development process.

A repeated request became a standard

One customer needed several external tools through the Model Context Protocol (MCP). I proposed a common connection and access model. We implemented it and documented how future connections work, including security requirements.

03
Customer experience

Clarifying the agent experience across channels

Problem
Customers could reach agents through different channels and start typing, but had little guidance about their capabilities. The experience depended on people knowing what to ask, while each channel offered different ways to explain and present the agent’s work.
What I did
I worked on the agent’s behaviour alongside onboarding and the channel interfaces. Through research and prototypes, I explored how each channel could help people understand the agent’s capabilities and begin using them. This included the dedicated WebUI experience, rather than treating it as a separate visual redesign.
Result
The redesigned WebUI and related customer portal are live.Customers described the new starting points and in-conversation feedback as convenient.
One part of the redesign: the WebUI
Before

Little guidance on where to begin. Feedback went by separate email.

After

Suggested starting questions. Feedback on each answer.

Illustration, not a product screenshot.

Key decisions

The problem with an empty input

People could type, but the interface did little to show what the agent could do.

Starting and responding

Suggested questions give people somewhere to begin. Feedback attached to an answer lets them flag a response and explain the problem in the same place.

Two interfaces, different jobs

The WebUI is for talking to agents. The customer portal is for managing them and inspecting their activity. One redesign, with the two flows kept distinct.

Onboarding

Onboarding is built into the experience to help new users understand the agent’s capabilities and get started.

More work at Manifold AI

From MVP to multi-tenant platform

Re-architected a four-service MVP into a 13-service multi-tenant platform: service boundaries, tenant isolation, asynchronous orchestration, audit logging and deployment infrastructure.

Self-service customer portal

Shipped a portal for workspace administration, usage analytics, automated billing and agent creation, replacing manual statistics reports and recurring account requests.

Reliability and cost control

Set up agent evaluation and regression workflows with tracing and failure analysis, plus model routing, fallback, caching, parallel tool execution and usage limits.

EU-only adaptation

Delivered an EU-only version of the platform for an enterprise customer by changing deployment and vendor choices. Led security reviews and SOC 2 / ISO 27001 preparation.

Product perspective

What makes a product useful

I judge a capability by the work someone can get done with it.

Our internal agent helps colleagues find platform information and check task status. For someone in sales, that information needs to be useful in a customer conversation. That gives me a concrete question to design around: what does this person need to leave with?

The same question shaped the customer experience. We worked on how people discover an agent’s capabilities and begin using them, alongside what the agent can do.

Exploring now: when an agent should take the initiative, and how a person should review or stop what it does.

Team leadership

How I lead engineering teams

My responsibilities include hiring and technical direction. The examples below show how I delegate work, develop engineers and learn from decisions that didn’t work.

Manifold AI

Planning, reviews and hiring

I lead technical direction for 13 engineers, including five direct reports. I own planning, design reviews, mentoring, performance reviews and promotion decisions, and I’ve completed ten engineering hires.

IT-Sprout

Started a CRM as its only engineer

Four engineers joined as the product grew. I led and mentored them while continuing to own the architecture.

Manifold AI

Making incidents less dependent on me

During a holiday in 2025, colleagues still called when something broke. I worked on system stability and helped engineers learn to investigate errors themselves. They became more independent in handling problems.

How I delegate

What I hand over and what I keep

For a new channel or integration, I delegate implementation and work through decisions with the engineer. I also use delegation to help someone learn. Work that needs context across the product, such as the redesign, stays closer to me.

What I’d do differently

Rolling out engineering checks

I introduced too many linters and checks at once. They overloaded the workflow, and engineers began bypassing them. I should have rolled them out gradually and checked how they fitted into the team’s daily work.

Experience

Full CV

Manifold AI

Mar 2025 to present
Technical LeadSince Jun 2025
Joined as Backend Infrastructure Developer

Lead the engineering team for an enterprise AI platform: product direction, platform architecture, customer interfaces, hiring and delivery.

Raccoon Gang

Apr 2024 to Mar 2025
Full Stack Developer

Built an Open edX modernization toolkit that removed 50+ duplicate packages, re-engineered failing Stripe payment flows without a full rewrite, and built a documentation-grounded AI assistant for support staff and client users.

IT-Sprout

Apr 2023 to Apr 2024
Full Stack Developer

Built a FastAPI, React and PostgreSQL CRM as the sole engineer, then led four more engineers. Split billing, credentials and credits into services and moved deployment toward serverless with Terraform and CloudFormation.

Mate Academy

Jul 2024 to Jun 2025
Python MentorVolunteer

Mentored aspiring developers through Python projects, Q&A and interview preparation.

Technical skills

Backend

  • Python
  • FastAPI
  • Django
  • Django REST Framework
  • Pydantic
  • TypeScript
  • Node.js
  • NestJS

Architecture and data

  • Multi-tenant SaaS
  • Distributed systems
  • Asynchronous orchestration
  • PostgreSQL
  • Redis
  • RabbitMQ
  • Qdrant
  • Celery

AI engineering

  • LangGraph
  • Pydantic AI
  • MCP
  • A2A
  • OpenAI
  • Anthropic
  • Mistral
  • RAG
  • Tool calling
  • Agent memory
  • Human-in-the-loop

Cloud and delivery

  • Azure
  • AWS
  • Terraform
  • CloudFormation
  • Docker
  • Kubernetes
  • GitHub Actions
  • Azure DevOps

Reliability

  • Pydantic Evals
  • Ragas
  • Regression testing
  • OpenTelemetry
  • Logfire
  • Sentry
  • Model routing and fallback

Security

  • SSO
  • Tenant isolation
  • Audit logging
  • Secrets management
  • Prompt-injection defenses
  • PII redaction
Contact

Get in touch

I’m exploring my next leadership role. If you’re hiring, send me the role and a little context about the product. Introductions to relevant teams are welcome too.

LinkedIn GitHub CV