Agent2Agent (A2A) is an open protocol that defines how artificial intelligence agents communicate with each other across different systems. It is intended to allow agents built by different vendors or frameworks to discover one another, exchange messages, and coordinate tasks. == History == The Agent2Agent protocol was announced by Google in April 2025 as an open standard for agent interoperability. In June 2025, Google transferred the protocol, its specification, and related software development kits to the Linux Foundation. The Linux Foundation established the Agent2Agent project to provide vendor-neutral governance. == Design == The A2A protocol supports communication between autonomous software agents operating across different platforms and organizations. It enables agents to discover one another and exchange structured messages without requiring shared internal state or proprietary integrations. A2A uses metadata documents, known as Agent Cards, to describe an agent's capabilities and how it can be accessed. These documents are exchanged using widely adopted web technologies such as HTTP and JSON-based messaging formats. A2A includes support for authentication and authorization to control which agents may participate in workflows. The protocol supports established security technologies including Transport Layer Security (TLS), JSON Web Tokens (JWTs), and OpenID Connect. A2A is often discussed alongside the Model Context Protocol (MCP). MCP focuses on connecting agents to tools and data sources, while A2A focuses on communication between agents themselves. == Adoption == At the time the Linux Foundation adopted the protocol, more than 100 technology companies had announced support for the Agent2Agent project. Microsoft stated that it planned to support the protocol in its AI platforms. == Reception == Technology press coverage has described A2A as an attempt to reduce fragmentation in AI agent ecosystems by providing a shared communication layer. TechRepublic characterized the protocol as part of a broader industry effort to reduce vendor lock-in for enterprise AI systems.
CrewAI
CrewAI is an open-source software framework and platform for building AI agents and multi-agent systems. Written primarily in Python, it is used to define artificial-intelligence agents, assign tasks to them, and coordinate their work through agent teams and workflows. The framework is associated with CrewAI Inc., a startup developing enterprise tools for automating business workflows with large language model-based agents. == History == CrewAI was first released on the Python Package Index in December 2023. The project was created by João Moura and later developed by CrewAI Inc. and open-source contributors. In October 2024, TechCrunch reported that CrewAI had raised $18 million across seed and Series A funding rounds from investors including Boldstart Ventures, Craft Ventures, Earl Grey Capital, and Insight Partners. The report also stated that Andrew Ng and HubSpot co-founder Dharmesh Shah had invested in the company. SiliconANGLE described the company as the developer of an open-source framework for building artificial-intelligence agents and reported that the funding consisted of a seed round led by Boldstart Ventures and a Series A led by Insight Partners. By late 2024, CrewAI had introduced commercial enterprise products built on top of its open-source components. TechCrunch reported that the company's enterprise offering added access controls, analytics, support, and templates for workflow automation. == Features == CrewAI is designed around groups of agents, sometimes called "crews", that can be assigned roles, goals, and tasks. The framework supports agent collaboration, task delegation, tool use, memory, and knowledge sources for retrieval-augmented generation workflows. The project describes two main building blocks: "Crews", which are used for autonomous agent collaboration, and "Flows", which are used for more controlled event-driven workflows. The framework is independent of LangChain and is released under the MIT License. It can be installed as a Python package and is commonly used with external large language model APIs or local models, depending on the developer's configuration. == Business model == CrewAI combines an open-source framework with commercial enterprise products. Its enterprise products are intended for organizations that need to build, monitor, and manage agent-based automations with additional security, observability, and administrative controls.
Too Good To Go
Too Good To Go is a service with a mobile application that connects customers to restaurants and stores that have surplus unsold food. The service covers major European cities, and in October 2020 started operations in North America. As part of the initiatives taken on the International Day of Awareness of Food Loss and Waste to reduce food loss and waste, the app is suggested alongside OLIO among many others. In 2023 Too Good To Go was the fastest-growing sustainable food app startup by number of downloads. As of August 2023, it claimed 164,000 businesses, serving 62 million users, have saved 155 million bags of food. As of March 2023, it claimed to have saved over 200 million meals. == History == The company was created in 2015 in Denmark by Thomas Bjørn Momsen, Klaus Bagge Pedersen, Adam Sigbrand and Brian Christensen. In 2017, Mette Lykke (co-founder of Endomondo) joined as CEO. In February 2019, the company raised an additional 6 million euros in a new round of investment. In August 2019, Too Good To Go was re-launched in Austria. In September 2019, Too Good To Go acquired the Spanish startup weSAVEeat and merged it into its own brand. In November 2019, the offer of Too Good To Go extended to plants through a partnership with the French retail plants company Jardiland. In December 2019, Too Good To Go partnered with the French grocery retail stores Intermarché, and donated 60K euros to the French charity Restaurants du Cœur. In October 2021, Bonnie Wright teamed up with Too Good To Go to drive the initiative to reduce food waste. == Corporate affairs == The key trends for the Danish entity Too Good To Go ApS are (as of the financial year ending December 31): == International expansion == As of March 2026 the company serves the European countries Austria, Belgium, Czechia, Denmark, the Faroe Islands, France, Germany, Ireland, Italy, the Netherlands, Norway, Poland, Portugal, Spain, Sweden, Switzerland, the United Kingdom. Outside of Europe the service is available in Australia, Canada, Japan, New Zealand and the United States. == Purpose == The purpose of Too Good To Go is to reduce food waste worldwide. It developed a mobile application that connects restaurants and stores that have unsold, surplus food, with customers who can then buy whatever food the outlet considers surplus to requirements—without being able to choose—at a much lower price than normal. The food on the app is priced at one-third its original price. The company claims this reduces the waste of food that would otherwise be discarded; food waste is a global problem that affects the environment. In three years active, the app reached more than 9.5 million users. As of 2022, more than 57.7 million users and 154,000 establishments have signed up, and 139 million meals have been collected. In 2019, the company had 350 employees in Europe. As of June 2023 the company was estimated to have 1,289 employees. == Use == Food outlets must notify the TGTG company about what they have available on each day, stating what sort of food they have (baked foods, meals, produce, vegan food), and the price for a 'surprise bag', whose contents they determine; the user cannot choose, but the original prices will be three or more times the TGTG price. Notification is made early based upon the quantity predicted to be left over, not at the end of a selling period. Users must register to use the service. A mobile phone with an Internet connection running Android or iOS is needed. The user runs the TGTG app, which lists outlets available within a chosen distance and time range. The customer can then order and pay for a 'surprise bag'. The supplier can cancel an order at any time if the expected surplus is not available—the purchaser is notified by text message—and the purchaser can cancel with two hours' notice. The phone must be taken to the food supplier in a specified pickup time window, often 30 or 60 minutes long, and the transaction is finalised by swiping the app—connected to the Internet—to confirm collection.
Systems development life cycle
The systems development life cycle (SDLC) describes the typical phases and progression between phases during the development of a computer-based system. These phases progress from inception to retirement. At base, there is just one life cycle, but the taxonomy used to describe it may vary; the cycle may be classified into different numbers of phases and various names may be used for those phases. The SDLC is analogous to the life cycle of a living organism from its birth to its death. In particular, the SDLC varies by system in much the same way that each living organism has a unique path through its life. The SDLC does not prescribe how engineers should go about their work to move the system through its life cycle. Prescriptive techniques are referred to using various terms such as methodology, model, framework, and formal process. Other terms are used for the same concept as SDLC, including software development life cycle (also SDLC), application development life cycle (ADLC), and system design life cycle (also SDLC). These other terms focus on a different scope of development and are associated with different prescriptive techniques, but are about the same essential life cycle. The term "life cycle" is often written without a space, as "lifecycle", with the former more popular in the past and in non-engineering contexts. The acronym SDLC was coined when the longer form was more popular and has remained associated with the expansion, even though the shorter form is popular in engineering. Also, SDLC is relatively unique as opposed to the TLA SDL, which is highly overloaded. == Phases == Depending on the source, the SDLC is described as having different phases and using different terms. Even so, there are common aspects. The following attempts to describe notable phases using notable terminology. The phases are somewhat ordered by the natural sequence of development, although they can be overlapping and iterative. === Conceptualization === During conceptualization (a.k.a. conceptual design, system investigation, feasibility), options and priorities are considered. A feasibility study can determine whether the development effort is worthwhile via activities such as understanding user needs, cost estimation, benefit analysis, and resource analysis. A study should address operational, financial, technical, human factors, and legal/political concerns. === Requirements analysis === Requirements analysis (a.k.a. preliminary design) involves understanding the problem and determining what is needed. Often this involves engaging users to define the requirements and recording them in a document known as a requirements specification. === Design === During the design phase (a.k.a. detail design), a solution is planned. The plan can include relatively high-level information such as describing the major components of the system. The plan can include relatively low-level information such as describing functions, screen layout, business rules, and process flow. The design phase is informed by the requirements of the system. The design must satisfy each requirement. The design may be recorded in textual documents as well as functional hierarchy diagrams, example screen images, business rules, process diagrams, pseudo-code, and data models. === Construction === During construction (a.k.a. implementation, production), the system is realized. Based on the design, hardware and software components are created and integrated. This phase includes testing sub-components, components and the integration of some components, but typically does not include testing at the complete system level. This phase may include the development of training materials, including user manuals and help files. === Acceptance === The acceptance phase (a.k.a. system testing) is about testing the complete system to ensure that it meets customer expectations (requirements). === Deployment === The deployment phase (a.k.a. implementation) involves the logistics of delivery to the customer. Some systems are deployed as a single instance (i.e. in the cloud), and deployment may be ad hoc and manual. Some systems are built in quantity and are associated with manufacturing process and commissioning. This phase may include training users to use the system. It may include transitioning future development to support staff. === Maintenance === During the maintenance phase (a.k.a. operation, utilization, support) development is largely inactive, although this phase does include customer support for resolving user issues and recording suggestions for improvement. Fixes and enhancements are handled by returning to the first phase, conceptualization. For minor changes, the cycle may be significantly abbreviated compared to initial development. === Decommission === Decommission (a.k.a. disposition, retirement, phase-out) is when the system is removed from use, i.e., when it reaches end-of-life. == Practices == === Management and control === SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives while executing projects. Control objectives are clear statements of the desired result or purpose and should be defined and monitored throughout a project. Control objectives can be grouped into major categories (domains), and relate to the SDLC phases as shown in the figure. To manage and control a substantial SDLC initiative, a work breakdown structure (WBS) captures and schedules the work. The WBS and all programmatic material should be kept in the "project description" section of the project notebook. The project manager chooses a WBS format that best describes the project. The diagram shows that coverage spans numerous phases of the SDLC, but the associated MCD (Management Control Domains) shows mappings to SDLC phases. For example, Analysis and Design is primarily performed as part of the Acquisition and Implementation Domain, and System Build and Prototype is primarily performed as part of delivery and support. === Work breakdown structured organization === The upper section of the WBS provides an overview of the project scope and timeline. It should also summarize the major phases and milestones. The middle section is based on the SDLC phases. WBS elements consist of milestones and tasks to be completed rather than activities to be undertaken, and have a deadline. Each task has a measurable output (e.g., an analysis document). A WBS task may rely on one or more activities (e.g., coding). Parts of the project needing support from contractors should have a statement of work (SOW). The development of an SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by contractors. === Baselines === Baselines are established after four of the five phases of the SDLC, and are critical to the iterative nature of the model. Baselines become milestones. functional baseline: established after the conceptual design phase. allocated baseline: established after the preliminary design phase. product baseline: established after the detailed design and development phase. updated product baseline: established after the production construction phase. In the following diagram, these stages are divided into ten steps, from definition to creation and modification of IT work products:
Recruitee
Tellent Recruitee is a cloud-based applicant tracking system (ATS) for talent acquisition owned by Tellent. It is used by internal HR teams for processes including job postings, candidate sourcing, reporting, and applicant tracking. == History == Perry Oostdam and Pawel Smoczyk founded Recruitee after working on a mobile gaming startup. The Recruitee was launched in August 2015. In September 2015, it received a seed funding round with participation from investors Robert Pijselman and Luc Brandts. Merger In February 2021, Recruitee and the Finnish HR software provider Sympa merged their operations, backed by the growth equity firm Providence Strategic Growth (PSG). Acquisition In 2022, the group acquired the French company Javelo and the German company kiwiHR. The parent company was subsequently renamed as Tellent while Recruitee renamed as Tellent Recruitee and continues to operate as a product unit within the Tellent group. == Platform == Tellent Recruitee is a customizable recruitment software. It functions as an ATS and talent acquisition platform and includes tools to create and publish job listings, source candidates, manage recruitment agencies, and track applicants through customizable pipelines. The interface allows drag-and-drop organization of candidates. The platform also includes features for team collaboration, such as shared notes, task assignments, and candidate evaluations. It also has integrated scheduling tools and automated email communication. Tellent Recruitee also provides analytics and reports on hiring and career site metrics. The software allows for customization of career site pages and application forms. It supports integrations with other HR and productivity software, such as WhatsApp, and has various AI functionalities to support with manual recruitment tasks.
ImageMixer
ImageMixer is a brand name of video editing software that edits digital video and still image in camcorders and authors to VCD and DVD. It is a second-party Japanese product, distributed by Pixela Corporation, a Japanese manufacturer of PC peripheral hardware and multimedia software. == Bundling == ImageMixer is widely used for several camcorder brands, such as JVC, Hitachi and Canon. Also, Sony has chosen to package ImageMixer with its DVD and HDD Handycam. == ImageMixer series == ImageMixer has other series of software for digital camera, such as ImageMixer Label Maker and ImageMixer DVD dubbing. ImageMixer also has movie editing solution for Macintosh. == Windows Vista version of ImageMixer == A Windows Vista version of ImageMixer has been developed (ImageMixer3).
Mojito (framework)
Mojito is an environment agnostic, Model-View-Controller (MVC) web application framework. It was designed by Yahoo. == Features == Mojito supports agile development of web applications. Mojito has built-in support for unit testing, Internationalization, syntax and coding convention checks. Both server and client components are written in JavaScript. Mojito allows developers designing web applications to leverage the utilities of both configuration and MVC framework. Mojito is capable of running on both JavaScript-enabled web browsers and servers using Node.js because they both utilize JavaScript. Mojito applications mainly consist of two components: JSON Configuration files: these define relationships between code components, assets, routing paths, and framework defaults and are available at the application and mojit level. Directories: these reflect MVC architecture and are used to separate resources such as assets, libraries, middleware, etc. == Architecture == In Mojito, both server and "client" side scripting is done in JavaScript, allowing it to run on both client and server thereby breaking the "front-end back-end barrier." It has both client and server runtimes. === Server runtime === This block houses operations needed by server side components. Services include: Routing rules, HTTP Server, config loader and disk-based loader. === Client runtime === This block houses operations called upon while running client sides components. Services include local storage/cache access and JSON based /URL based loader === Core === Core function can be accessed on client or server. Services include Registry, Dispatcher, Front controller, Resource store. === Container === mojit object comes into the picture. This container also include the services used by mojits. API and Mojito services are the blocks which caters to services needed for execution of mojits. === API (Action Context) === Mojito services are a customizable service block. It offers mojits a range of services which might be needed by mojit to carry out certain actions. These services can be availed at both client and server side. Reusable services can be created and aggregated to the core here. == Mojits == Mojits are the modules of a Mojito application. An application consists of one or more mojits. A mojit encompasses a Model, Views and a Controller defined by JSON configuration files. It includes a View factory where views are created according to the model and a View cache that holds frequently requested views to aid performance. === Application Architecture === A Mojito application is a set of mojits facilitated by configurable JSON files which define the code for model, view and controller. This MVC structure works with API block and Mojito services, and can be deployed at both client and server side. While the application is deployed at client side, it can call server-side modules using binders. Binders are mojit codes that let mojits request services from each other. Mojit Proxy acts as an intermediary between binders and mojit's API (application context) block and other mojits. Controllers are command-issuing units of mojits. Models mirror the core logic and hold data. Applications can have multiple models. They can be centrally accessed from controllers. View files are created in accordance with controllers and models, and are marked-up before they are sent to users as output. === Application Directory Structure === Directory structure of a Mojito application with one mojit: [mojito_app]/ |-- application.json |-- assets/ | `-- favicon.icon |-- yui_modules/ | `-- .{affinity}.js |-- index.js |-- mojits/ | `-- [mojit_name | |-- assets/ | |-- yui_modules/ | | `-- .{affinity}.js | |-- binders/ | | `-- {view_name}.js | |-- controller.{affinity}.js | |-- defaults.json | |-- definition.json | |-- lang/ | | `-- {mojit_name}_{lang}.js | |-- models/ | | `-- {model_name}.{affinity}.js | |-- tests/ | | |-- yui_modules/ | | | `-- {module_name}.{affinity}-tests.js | | |-- controller.{affinity}-tests.js | | `-- models/ | | `-- {model_name}.{affinity}-tests.js | `-- views/ | |-- {view_name}.{view_engine}.html | `-- {view_name}.{device}.{view_engine}.html |-- package.json |-- routes.json (deprecated) |-- server.js == Model, View and Controller == The Model hosts data, which is accessed by the Controller and presented to the View. Controller also handles any client requests for data, in which case controller fetches data from the model and passes the data to the client. All three components are clustered in the mojit. Mojits are physically illustrated by directory structures and an application can have multiple mojits. Every mojit can have one controller, one or more views and zero or more models. === Model === The model it represents the application data and is independent of view or controller. Model contains code to manipulate the data. They are found in the models directory of each mojit. Functions include: Storing information for access by controller. Validation and error handling. Metadata required by the view === Controller === The controller acts like a connecting agent between model and view. It supplies input to Model and after fetching data from model, passes it to View. Functions include Redirection Monitors authentication Web safety Encoding === View === The view acts as a presentation filter by highlighting some model attributes and suppressing others. A view can be understood as a visual permutation of the model. The view renders data received from controller and displays it to the end user.